Sichere Unternehmenssoftware – Code-Prüfung bei individueller Softwareentwicklung
Sicherheit

KI Software Sicherheit: Ist mit KI gebaute Software sicher?

Mit KI gebaute Software ist genau so sicher wie der Prüfschritt, der danach kommt. Die Werkzeuge selbst sind nicht das Problem — auch wir entwickeln mit KI-Unterstützung, und das macht Software schneller und günstiger. Riskant wird es dort, wo niemand mehr kontrolliert, was da eigentlich gebaut wurde. Dieser Artikel erklärt die sechs häufigsten Lücken ohne Fachchinesisch und gibt dir fünf Fragen mit, mit denen du jedes Software-Angebot prüfen kannst.

Warum das Thema gerade jetzt aufkommt

In Entwickler-Communities kursieren seit einiger Zeit Listen mit Sicherheitslücken, die in schnell zusammengeklickter KI-Software immer wieder in derselben Form auftauchen. Der Begriff dafür heißt „Vibe Coding": Man beschreibt einer KI, was die App können soll, die KI schreibt den Code, das Ergebnis sieht nach wenigen Stunden fertig aus — und geht online, ohne dass jemand mit Erfahrung draufgeschaut hat.

Für dich als Geschäftsführer ist das aus einem sehr praktischen Grund relevant: Software wird dadurch billiger angeboten. Wenn du gerade Angebote vergleichst, wirst du große Preisunterschiede sehen. Das kann völlig in Ordnung sein — oder eben nicht. Der Unterschied liegt nicht in der Oberfläche, die du im Verkaufsgespräch siehst, sondern in dem, was danach passiert ist.

Denn früher stand zwischen „funktioniert bei mir am Rechner" und „läuft beim Kunden" immer ein erfahrener Entwickler. Jemand, der nicht nur fragt „tut es das, was es soll?", sondern auch „was passiert, wenn jemand es absichtlich falsch benutzt?". Genau dieser zweite Blick fällt weg, wenn Software nur noch generiert und sofort ausgeliefert wird. Und dann gehen Fehler live, die eine KI nie von selbst meldet — weil aus ihrer Sicht ja alles funktioniert.

Sechs Sicherheitslücken, die immer wieder auftauchen

Diese sechs Punkte sind kein theoretisches Risiko-Szenario, sondern die Klassiker, die in solchen Listen fast immer vorkommen. Ich erkläre sie bewusst so, dass du sie ohne technischen Hintergrund einordnen kannst.

01
Fremde Daten über die Adresszeile lesen
Du öffnest deine Rechnung, oben in der Adresszeile steht /rechnung/1045. Du änderst die Zahl auf 1047 — und siehst die Rechnung eines anderen Kunden. Der Grund: Die Software prüft nur, WAS gefragt wird, aber nicht, WER fragt. Ein sauber gebautes System muss bei jedem einzelnen Aufruf gegenprüfen, ob genau dieser angemeldete Benutzer genau dieses Dokument sehen darf. Das ist kein Sonderfall, das ist Grundlage.
02
Die Datenbank ist direkt aus dem Browser erreichbar
Moderne Baukästen wie Supabase oder Firebase nehmen Entwicklern viel Arbeit ab: Die App im Browser spricht direkt mit der Datenbank, ohne Umweg. Das ist schnell — aber nur sicher, wenn die Zugriffsregeln in der Datenbank sauber gesetzt sind. Sind sie das nicht (und in der Grundeinstellung sind sie oft sehr offen), kann jeder mit ein wenig Wissen den kompletten Datenbestand auslesen. Ohne Passwort, ohne Einbruch, einfach durch Fragen.
03
Preise und Berechtigungen werden im Browser entschieden
Alles, was auf dem Gerät deines Kunden passiert, kann dein Kunde verändern. Wenn der Preis, der Rabatt oder die Berechtigung „ist Administrator" im Browser berechnet und dann an den Server geschickt wird, kann jemand diesen Wert unterwegs abändern. Aus 890 Euro werden 8,90 Euro, aus „normaler Benutzer" wird „Administrator". Die Regel dahinter: Der Browser darf anzeigen, aber niemals entscheiden. Preise und Rechte gehören auf den Server.
04
Kein Limit auf teure Funktionen
Viele Apps nutzen Dienste, die pro Aufruf Geld kosten — KI-Auswertungen, SMS-Versand, Kartendienste. Wenn so eine Funktion ohne Begrenzung von außen erreichbar ist, kann sie automatisiert millionenfach aufgerufen werden. Der Schaden entsteht dabei nicht durch Datenverlust, sondern auf deiner Rechnung. Ein Wochenende reicht. Ein Limit pro Benutzer und pro Stunde kostet in der Entwicklung fast nichts — wenn jemand daran denkt.
05
Selbstgebaute Login-Systeme statt erprobter Bausteine
Ein Anmeldesystem wirkt simpel: Benutzername, Passwort, fertig. Tatsächlich steckt darin sehr viel Detail — wie Passwörter verschlüsselt abgelegt werden, wie Sitzungen ablaufen, was bei „Passwort vergessen" passiert, wie man automatisierte Anmeldeversuche bremst. Für all das gibt es seit Jahren erprobte, millionenfach geprüfte Bausteine. Eine KI baut auf Zuruf aber gerne eine hübsche Eigenkonstruktion — die im Alltag funktioniert und im Ernstfall nicht hält.
06
Dateiablagen, deren Inhalt jeder auflisten kann
Hochgeladene Dateien — Verträge, Fotos, Ausweiskopien, Befundberichte — landen in einem Online-Speicher. Häufig sind die einzelnen Dateien zwar nicht verlinkt, das Verzeichnis selbst lässt sich aber von außen auflisten. Dann bekommt man mit einem einzigen Aufruf eine Liste aller Dateien und kann sie der Reihe nach herunterladen. „Privat" heißt hier eben nur „nicht verlinkt", nicht „geschützt". Der Unterschied ist im Alltag unsichtbar und im Schadensfall entscheidend.

Warum diese Fehler bei einem normalen Test nie auffallen

Alle sechs Punkte haben eine Gemeinsamkeit, und die ist der eigentliche Kern des Problems: Die App funktioniert perfekt, solange man sie normal benutzt. Du klickst dich durch, legst einen Kunden an, schreibst eine Rechnung, lädst ein Foto hoch — alles läuft. Auch beim Testen mit dem Team wird nichts auffallen, weil niemand von euch auf die Idee kommt, die Zahl in der Adresszeile zu verändern oder einen Preis auf dem Weg zum Server abzufangen.

Genau deshalb ist „wir haben es ausführlich getestet" keine Aussage über Sicherheit. Ein Test prüft, ob die Software das Richtige tut. Sicherheit prüft, ob sie das Falsche verhindert. Das sind zwei verschiedene Arbeitsschritte, und der zweite wird gerne weggelassen, weil man sein Fehlen nicht sieht.

Gut zu wissen

Keiner dieser Punkte ist ein Argument gegen KI in der Softwareentwicklung. Wir bauen unsere eigenen Produkte mit KI-Unterstützung und liefern dadurch schneller und günstiger als früher. Der Unterschied liegt allein darin, ob nach dem Bauen noch jemand mit Erfahrung prüft, was gebaut wurde — und ob dieser Prüfschritt fix im Ablauf verankert ist oder zufällig passiert.

5 Fragen, die du deinem Software-Anbieter stellen solltest

Du musst nicht beurteilen können, ob Code gut geschrieben ist. Aber du kannst am Antwortverhalten sehr schnell erkennen, ob jemand über diese Dinge nachgedacht hat. Diese fünf Fragen funktionieren bei jedem Anbieter, egal ob Agentur, Einzelentwickler oder fertiges Produkt:

Frage Woran du eine gute Antwort erkennst
Wo liegen meine Daten — und sind sie von anderen Kunden getrennt?Konkrete Angabe zu Serverstandort und Trennung. „Jeder Kunde hat eine eigene Datenbank" ist stärker als „die Daten sind natürlich getrennt". Ausweichende Antworten sind hier ein Warnsignal.
Wer prüft, dass ich nur meine eigenen Daten sehe?Die Antwort muss „der Server, bei jeder Anfrage" enthalten. Wenn stattdessen erklärt wird, dass man fremde Datensätze in der Oberfläche gar nicht anklicken kann, wurde die Frage nicht verstanden.
Wie oft wird gesichert — und wurde die Rücksicherung schon einmal getestet?Der zweite Teil der Frage ist der wichtige. Backups haben fast alle. Ob sich daraus im Ernstfall tatsächlich ein funktionierendes System wiederherstellen lässt, hat kaum jemand ausprobiert.
Bekomme ich meine Daten heraus, wenn ich kündige?Eine klare Zusage inklusive Format (z. B. Excel-Export, PDF-Archiv, Datenbank-Auszug) und Frist. Wenn es dazu keine Regelung gibt, ist der Wechsel später faktisch nicht möglich.
Wer haftet — und gibt es einen AV-Vertrag nach DSGVO?Ein Auftragsverarbeitungsvertrag ist bei personenbezogenen Daten Pflicht, nicht optional. Ein Anbieter, der ihn ohne Rückfrage bereitstellt, hat sich mit dem Thema befasst.

Du musst die Antworten nicht technisch bewerten können. Achte nur darauf, ob jemand konkret antwortet oder allgemein bleibt. „Da müssen Sie sich keine Sorgen machen" ist auf keine dieser fünf Fragen eine Antwort.

Sichere Unternehmenssoftware: wie wir es machen

Damit das nicht bei allgemeinen Ratschlägen bleibt, hier ganz sachlich, wie wir unsere Software für KMU in Österreich aufsetzen. Nicht weil das besonders aufwendig wäre — sondern weil es sich mit etwas Disziplin einmal einrichten und dann dauerhaft betreiben lässt:

Was das für dich heißt, wenn du gerade ein Angebot vergleichst

Ein günstiges Angebot ist kein Warnsignal. KI-Werkzeuge senken die Entwicklungskosten tatsächlich, und dieser Vorteil soll bei dir ankommen — nicht in der Marge einer Agentur verschwinden. Das Warnsignal ist ein anderes: wenn niemand benennen kann, wer nach dem Bauen geprüft hat und wonach.

Für dich als Betrieb geht es dabei selten um spektakuläre Angriffe. Es geht um den unangenehmen Fall, dass ein Kunde zufällig die Daten eines anderen Kunden sieht, dass hochgeladene Dokumente auffindbar sind oder dass am Montag eine vierstellige Rechnung für einen Dienst im Postfach liegt, den übers Wochenende jemand automatisiert leergelaufen hat. Das sind keine Katastrophen im Filmformat, aber genau die Dinge, die Vertrauen kosten und Zeit fressen.

Sichere Unternehmenssoftware ist am Ende keine Frage von großen Budgets, sondern von wenigen sauber gesetzten Grundregeln — getrennte Daten, Prüfung am Server, erprobte Bausteine, getestete Backups. Wenn dein Anbieter diese vier Punkte ohne Zögern beantworten kann, bist du in aller Regel gut aufgestellt.

Häufige Fragen

Nicht automatisch. Unsicher wird sie erst, wenn niemand den fertigen Code prüft. Die KI schreibt, was funktioniert — sie denkt aber nicht daran, wie jemand die Software absichtlich missbrauchen könnte. Diesen Schritt muss ein erfahrener Entwickler übernehmen.
Am Prozess, nicht am Bildschirm. Frag nach: Wo liegen meine Daten und sind sie von anderen Kunden getrennt? Wer prüft, dass ich nur meine eigenen Daten sehe? Wie oft wird gesichert und wurde die Rücksicherung getestet? Wer keine konkrete Antwort geben kann, hat es vermutlich nie geprüft.
Vibe Coding bezeichnet das schnelle Zusammenbauen von Software mit KI-Werkzeugen, ohne dass der entstandene Code fachlich geprüft wird. Das Ergebnis sieht fertig aus und funktioniert im normalen Gebrauch — die Prüfung auf Missbrauchsfälle fehlt aber komplett.
Nein. Der Serverstandort ist eine rechtliche Voraussetzung, aber keine Sicherheitsmaßnahme. Eine App mit offener Datenbank ist auf einem Server in Linz genauso angreifbar wie auf einem Server in den USA. Standort und saubere Zugriffsprüfung sind zwei verschiedene Themen.
In den meisten Fällen ja. Zugriffsprüfungen am Server, Limits auf teure Funktionen und ein erprobtes Login-System lassen sich nachrüsten, ohne die App neu zu bauen. Zuerst braucht es aber eine ehrliche Bestandsaufnahme, welche Lücken tatsächlich offen sind.
Daniel Reichhart
Daniel Reichhart
Webentwickler und Automatisierungsexperte aus Linz. Ich helfe KMU in Oberösterreich dabei, Büroprozesse zu automatisieren und individuelle Software zu entwickeln.
Jetzt anfragen →
Kostenlos & unverbindlich

Unsicher, ob deine Software sauber gebaut ist?

Schreib mir kurz, welche Software du gerade nutzt oder angeboten bekommst —
ich schau sie mir an und melde mich innerhalb eines Werktags.

Jetzt anfragen →