Was du beim Vibe Coding nicht siehst

670 KI-generierte Websites wurden untersucht. Fast jede zweite Datenbank war von außen zugänglich. Der Fehler sah nicht wie ein Fehler aus.

Eine Passage aus dem heutigen Golem-Bericht hat mich nicht losgelassen:

„Die App lädt. Formulare speichern Daten. Testkonten funktionieren. Erst der externe Blick zeigt, dass aus einem Backend ein öffentlicher Datenkanal geworden ist.”

Kein abgestürzter Build. Kein roter Fehler. Kein 404. Die App hat funktioniert.

Was die Recherche gefunden hat

IT-Sicherheitsforscher Christopher Helm hat 670 deutschsprachige Websites untersucht, die mit KI-Tools gebaut wurden. In fast jeder zweiten Datenbank waren von außen Zugriffe möglich. Gefunden: Gesundheitsdaten, Passwörter, Bewerbungsunterlagen, Kundendaten, technische Zeichnungen.

Betroffen waren nicht nur frühe Prototypen. Auch ein Anbieter von IT-Sicherheitsschulungen für Behörden, ein deutscher Industrieanlagenbauer, eine Mastercard-Subdomain, ein australischer Energieversorger.

Die Recherche basiert auf einer Untersuchung der Zeit (Paywall), Golem hat die Ergebnisse öffentlich zusammengefasst.

Der Unterschied zwischen funktionieren und sicher sein

Das Technische dahinter lässt sich grob so erklären: Supabase, ein beliebtes Backend bei KI-generierten Projekten, hat eine Schutzschicht namens Row Level Security. Diese Schicht bestimmt, wer auf welche Daten zugreifen darf.

Wer Tabellen anlegt, ohne diese Schicht zu aktivieren, baut eine App, die von außen wie fertig aussieht. Die App lädt. Daten werden gespeichert. Und trotzdem ist alles offen. Fehlende RLS ist nur eines der Muster. API-Keys im Frontend, parallele Auth-Systeme und fehlende Zugriffskontrollen tauchen in fast jedem KI-generierten Projekt auf.

Die KI setzt diese Schicht nicht automatisch, wenn sie nicht darum gebeten wird. Niemand sieht den Fehler, weil er sich nicht zeigt.

Warum das kein normaler Bug ist

Klassische Fehler zeigen sich. Falsches Ergebnis, Exception, falsches Verhalten. Man sucht, man findet.

Eine fehlende Schutzschicht zeigt sich nicht. Die App läuft. Tests laufen durch. Die KI meldet “Success”.

Golem fasst es so zusammen: KI-generierte Projekte können funktionierende Anwendungen erzeugen, aber zugleich Sicherheitsannahmen übernehmen, die im produktiven Betrieb nicht tragen.

Das gilt auch für das, was die KI nicht generiert. Wenn ein Modell eine Tabelle erstellt und die Zugriffspolitik nicht setzt, weil niemand danach gefragt hat, dann fehlt etwas, das niemand sieht.

Das Skalierungsproblem

Golem schreibt: Ein einzelnes Team kann sich vertippen. Ein Codegenerator wiederholt denselben Fehler projektweit. Er trägt seine Annahmen in jedes neue Projekt.

Wenn das Modell eine Tabelle ohne Schutzschicht anlegt, passiert das nicht einmal, sondern tausendmal.

Bessere Modelle vergrößern das Problem eher, als dass sie es lösen. Je mehr Code generiert wird, desto mehr Träger für dasselbe Muster. Vibe Coding ist inzwischen ein Mainstream-Problem: Apple hat reagiert und KI-generierte Apps aus dem Store entfernt.

Was der externe Blick bedeutet

Die Zeit beschreibt den Fall einer Gründerin mit nachhaltigem Onlineshop. Sie hat erst durch die Recherche erfahren, dass Kundendaten erreichbar waren.

Eine unabhängige Prüfung gehört davor. Nicht danach.

Christopher Helm sagt: Sicherheit ist kein Schalter. Mit ausreichend Kreativität und Zeit lassen sich immer Schwachstellen finden. Entscheidend ist, die eigenen Angriffsflächen zu kennen.

Welche Tabellen, Rollen, Regeln und Schlüssel sind im produktiven Betrieb erreichbar? Wer hat das geprüft? Wer wurde gefragt?

Wenn die Antwort “niemand außer der KI” ist, dann ist das die Lücke.

Wenn du mit KI gebaut hast und vor dem Launch stehst, schaue ich mir den Code an, bevor echte Nutzerdaten ins System kommen. Die App kann sich selbst nicht prüfen.