9. Juni 2026
Was die KI in deinem Code wirklich gebaut hat
API-Keys im Frontend, parallele Auth-Systeme, keine Row Level Security: Die häufigsten Sicherheitsprobleme in Lovable-, Cursor- und Bolt-Projekten, mit konkreten Fixes.
Datenstand 2025 Studien, Zahlen und Beobachtungen in diesem Beitrag stammen aus diesem Zeitraum, nicht von heutigen Agenten wie Claude Code mit Opus 5.5.
Du siehst die App. Die KI sieht den Prompt.
Du promptest: “Füge Login hinzu.” Die KI baut ein Login. Es funktioniert. Du siehst einen Anmeldebildschirm, du kannst dich einloggen, die App geht weiter.
Was du nicht siehst: Die KI hat das gelöst, was du gefragt hast. Nicht unbedingt die sicherste Lösung. Nicht unbedingt die, die im App Store akzeptiert wird.
Heutige Agenten lesen das ganze Repo, arbeiten mit einer CLAUDE.md und einem Plan-Modus. Das hilft. Es passiert trotzdem, wenn niemand fragt und niemand prüft. Wer in der nächsten Session sagt “das Login funktioniert nicht richtig, fix es”, bekommt womöglich ein zweites Login.
Ohne unabhängiges Audit sieht man das nicht. Die App läuft ja.
Die häufigsten Befunde
Aus echten Audits von Vibe-Coding-Projekten, anonymisiert, aber unverändert in der Substanz. Stand der Audits: 2025, mit den Tools von damals.
1. Zugangsschlüssel im ausgelieferten Code
Das häufigste Problem. Die KI braucht einen Schlüssel (einen geheimen Zugangscode, API-Key genannt), um Datenbank oder externe Dienste anzubinden. Also schreibt sie ihn dahin, wo er am schnellsten funktioniert: mitten in den Code der App.
Das Problem: Dieser Code wird an die Nutzer ausgeliefert. Bei einer Web-App liegt er im Browser. Bei einer App aus dem Store lässt er sich aus dem Installationspaket herauslesen. Jeder kann ihn lesen. Was das im Ernstfall bedeutet, hat t3n dokumentiert: ein Entwickler bekam eine Rechnung über 82.000 Dollar, weil sein Schlüssel im Code lag.
Wie du es erkennst: Frag den Entwickler oder die KI direkt, wo die Schlüssel gespeichert sind. Stehen sie im Code der App selbst statt in einer geschützten Konfiguration auf dem Server, sind sie öffentlich.
Was du tun kannst: Geheime Schlüssel gehören auf einen Server, den nur du kontrollierst. Die App fragt dort an und bekommt nur das Ergebnis zurück.
2. Mehrere Anmeldesysteme parallel
Entscheidungen, die nirgends festgehalten sind, gehen leicht verloren. Wenn du in Prompt 12 ein Login baust und in Prompt 47 sagst “der User soll sich anmelden können”, baut der Agent möglicherweise ein zweites System. Oder ein drittes.
Wer mitten im Projekt die Anmeldelösung wechselt, bekommt das Neue eingebaut. Das Alte bleibt manchmal liegen, wenn niemand ausdrücklich das Aufräumen verlangt. Der alte Code liegt still im Projekt, bis er irgendwann mit dem neuen in Konflikt gerät.
Wie du es erkennst: Frag nach, wie sich Nutzer in deiner App anmelden und wie viele Anmeldewege es im Code gibt. Wenn es mehr als einen gibt, hast du ein Problem.
Was du tun kannst: Entscheide dich für ein Anmeldesystem. Ein einziges. Lass den Rest löschen. Halte in der CLAUDE.md fest, welches gilt, und dass der Agent kein eigenes Login nebenher baut.
3. Keine Zugriffsregeln in der Datenbank
Datenbanken bei Supabase (einem beliebten Datenbank-Dienst) ohne Row Level Security sind offen wie ein Scheunentor. Diese Sicherheitsfunktion legt fest, wer welche Zeilen sehen darf. Fehlt sie, kann jeder angemeldete Nutzer alle Daten aller Nutzer lesen, und oft auch ändern und löschen.
Die Schutzfunktion bleibt aus, wenn niemand danach fragt. Die App funktioniert auch ohne sie. Der Prototyp läuft. Erst wenn jemand von außen direkt auf die Datenbank zugreift, wird das Problem sichtbar. Bei einer Analyse von 670 KI-generierten Websites aus 2025 war fast jede zweite Datenbank von außen zugänglich.
Wie du es erkennst: Im Supabase-Dashboard zeigt jede Tabelle an, ob “RLS enabled” aktiv ist. Wenn nicht: offen. Lass den Agenten die Zugriffe mit zwei Testnutzern prüfen und lass zusätzlich jemand Unabhängiges nachsehen.
Was du tun kannst: Schalte die Schutzfunktion für jede Tabelle ein und lege Regeln fest, wer was sehen und ändern darf. Mindestens: Jeder Nutzer sieht nur seine eigenen Daten.
4. Zu viele Datenbank-Tabellen
Jeder Prompt, der eine neue Funktion beschreibt, kann eine neue Tabelle erzeugen. Ohne Vorgabe zur Gesamtstruktur optimiert der Agent darauf, dass dieser Prompt jetzt funktioniert.
Dutzende Tabellen für eine erste Version mit wenigen Kernfunktionen. Keine dokumentierten Änderungsschritte. Jede Änderung direkt in der Datenbank, ohne Möglichkeit sie rückgängig zu machen.
Wie du es erkennst: Zähle die Tabellen. Wenn du mehr als 10-12 für eine erste Version hast, ist wahrscheinlich etwas schief gelaufen.
Was du tun kannst: Zeichne auf einem Blatt Papier deine drei Kernfunktionen. Welche Daten braucht jede? Welche Tabellen gehören zusammen? Dann bereinigen und Änderungen künftig nachvollziehbar festhalten.
5. DSGVO: Unvollständig oder fehlend
Kein Einwilligungsdialog. Keine Datenschutzerklärung. Kein Löschrecht. Kein Auftragsverarbeitungsvertrag mit dem Hosting-Provider. Manchmal sensible Daten (Gesundheit, Finanzen) unverschlüsselt gespeichert.
Die KI kennt DSGVO als Konzept. Von sich aus setzt sie nicht alles um, und ein Auftrag wie “mach die App DSGVO-konform” ist zu vage. Dabei kann ein Cookie-Banner herauskommen, der für eine native App irrelevant ist. Das Verzeichnis der Verarbeitungen, den Serverstandort und die Verträge musst du selbst klären.
Wie du es erkennst: Frag dich: Kann ein User seine Daten exportieren? Kann er seinen Account löschen? Gibt es eine Datenschutzerklärung? Weißt du, wo die Daten gespeichert werden und ob der Server in der EU steht?
Was du tun kannst: DSGVO ist kein Feature, das du einmal implementierst. Es ist eine Anforderung, die du von Anfang an mitdenkst. Account-Löschung, Datenexport, Einwilligung, Impressum, Datenschutzerklärung: das sind Pflichtfelder für den Store.
Das Muster
Keines dieser Projekte musste komplett neu geschrieben werden. Das ist die gute Nachricht. Die KI baut funktionierenden Code. Die Grundstruktur stimmt meistens. Die Screens funktionieren. Die Logik ist da.
Aber die Stellen, an denen es scheitert, sind oft dieselben: Sicherheit, Architektur, Recht. Das sind die Dinge, die kein User sieht, die aber darüber entscheiden, ob die App im Store akzeptiert wird, ob sie sicher ist, ob sie skaliert. Warum Vibe Coding inzwischen ein Mainstream-Problem ist, zeigen die Reaktionen von Apple und die aktuelle t3n-Recherche.
Gefährlich wird es, wenn niemand nach diesen Stellen fragt und niemand prüft. Die App auf deinem Handy funktioniert einwandfrei.
Diplom-Informatiker · 25 Jahre Entwicklung · LinkedIn
Audit-Bericht, Codequalität-Guide, 1 Call · ab 1.400 € zzgl. MwSt.
Weitere Artikel
11. September 2026
Deine App schaltet sich selbst frei
Der Kauf-Dialog meldet Erfolg, die App schaltet Pro frei. Damit entscheidet die App selbst, wer bezahlt hat. Umgehen lässt sich das in Sekunden.
4. September 2026
Du versteckst den falschen Schlüssel
Der öffentliche Supabase-Schlüssel gehört in die App, der ist mit Absicht öffentlich. Der geheime umgeht jede Zugriffsregel. Vier Orte, an denen er nicht landen darf.