Sind Vibe-Coding-Apps sicher? 8 Sicherheitslücken im Check

Sind Vibe-Coding-Apps sicher?

Nicht von Haus aus: Alle hier zitierten großen Studien fanden bei einem großen Teil der untersuchten Apps ernste Sicherheitslücken ^[3][4][5]. Die Apps funktionieren meist. Das Problem ist, was sie Fremden erlauben.

Eine Prüfung von 2026 sammelte 9.041 Open-Source-Apps, die mit Claude Code und Lovable gebaut wurden, und untersuchte 200 davon, die öffentlich betrieben wurden. Sie fand 1.186 Schwachstellen, und 182 der 200 Apps (91,0 %) hatten mindestens eine ^[4]. Von diesen Mängeln wurden 65,77 % als kritisch oder hoch eingestuft, darunter 18,47 % kritisch ^[4].

Die Autoren prüften auch, ob bessere Prompts und Agenten-Setups das Problem beheben. Sie verringerten es, beseitigten es aber nicht, und dieselbe Aufgabe konnte bei drei Durchläufen einmal ein sicheres und beim nächsten Mal ein unsicheres Ergebnis liefern ^[4]. Ein sauberes Ergebnis bei einem Build sagt also wenig über den nächsten.

Die Grundlagen der Methode erklärt der Pouyam-Ratgeber Vibe Coding Explained: What It Is, How It Works and the Real Risks. Für ein erstes Projekt liefert Vibe Coding for Beginners: How to Start Safely in 2026 einen Startplan. Diese Seite geht eine Ebene tiefer: die konkreten Lücken und wie man jede davon testet.

Was finden Sicherheitsstudien in Vibe-Coding-Apps?

Vier unabhängige Quellen zeigen auf dieselbe Schwachstelle: Daten, die die falsche Person lesen oder ändern kann ^[1][3][4][5].

• Prüfung von 200 veröffentlichten Apps (2026): Fehlerhafte Zugriffskontrolle war die größte Kategorie mit 339 von 1.186 Mängeln (28,58 %) und betraf 64,00 % der Apps. Injection betraf 54,00 % und Authentifizierungsfehler 51,50 % ^[4].
• ACM-CCS-Studie 2026: In 8.641 Lovable-Repositorys mit vollständiger Historie waren 11,2 % der Datenbank-Leseregeln für nicht angemeldete Besucher offen, und 61,2 % der Repositorys hatten mindestens eine solche Regel. Ein Wiederholungstest bestätigte die Offenlegung in 353 von 400 Stichproben ^[5].
• Escape (Oktober 2025): Ein passiver Scan von mehr als 5.600 öffentlichen Apps auf Plattformen wie Lovable, Base44 und Create.xyz fand mehr als 2.000 Schwachstellen, über 400 offengelegte Geheimnisse und 175 Fälle persönlicher Daten, darunter Krankenakten, IBANs (Kennungen von Bankkonten), Telefonnummern und E-Mail-Adressen ^[3].
• CVE-2025-48757 (2025): Ein am 21. März 2025 abgeschlossener Scan fand 303 Datenbank-Endpunkte in 170 von 1.645 Lovable-Projekten, etwa 10,3 %, mit unzureichenden Zeilenregeln ^[1].

Escape betont, dass der Scan nichts Zerstörerisches tat, die Zahlen also eine Untergrenze sind; ein tieferer Test würde mehr finden ^[3]. Dieselbe Vorsicht gilt für alle Zahlen hier: Die Studien zählen, was von außen sichtbar war.

Warum bauen KI-Tools unsichere Apps?

Weil die Tools auf eine funktionierende App optimieren und Sicherheitsregeln von geschäftlichen Details abhängen, die im Prompt selten stehen ^[4][11].

Funktionierender Code ist leicht zu prüfen: Die Seite lädt, der Button reagiert. Wer welchen Datensatz sehen darf, ist eine geschäftliche Entscheidung, und wenn niemand sie aufschreibt, muss das Tool raten. Die Prüfung von 2026 führt die Mängel auf acht wiederkehrende Fehlermuster zurück, gruppiert in drei Grenzen von KI-Agenten: Gedächtnis, Zielsetzung und Wissen ^[4].

Breite Tests von KI-Modellen zeigen dieselbe Lücke. Der GenAI Code Security Report 2026 von Veracode ergab, dass in seinen Tests rund 44 % der Aufgaben zur Codeerzeugung eine Sicherheitslücke einführten ^[11]. Ein von AWS zitierter Benchmark ergab, dass die beste von 12 Agenten-Konfigurationen 57 % der Aufgaben korrekt löste, aber nur 11,8 % korrekt und zugleich sicher ^[10].

Viele Vibe-Coding-Apps verlagern die Sicherheit zudem in die Datenbank. Der Browser spricht direkt mit einer gehosteten Datenbank, sodass deren Regeln das Einzige zwischen einem Besucher und jeder Zeile sind ^[1][6]. Fehlen die Regeln oder sind sie zu weit gefasst, kann jeder, der die Adresse kennt, alles abfragen.

Welche 8 Sicherheitslücken sollte ich zuerst prüfen?

Beginnen Sie mit den Lücken, die die Studien am häufigsten finden, geordnet nach dem möglichen Schaden ^[1][3][4][5].

1. Offene Datenbankregeln: Tabellen ohne Row Level Security oder mit Regeln, die jedem Besucher alle Zeilen zeigen. Das war die Ursache von CVE-2025-48757 und der ACM-Befunde ^[1][5].
2. Fehlerhafte Zugriffskontrolle: Ein angemeldeter Nutzer öffnet den Datensatz eines anderen, indem er eine ID in der Adresse oder Anfrage ändert. Das war die größte Kategorie der Prüfung von 2026 ^[4].
3. Geheime Schlüssel im Browser: ein Secret- oder service_role-Schlüssel von Supabase, ein Zahlungsschlüssel oder ein Schlüssel eines KI-Anbieters im Frontend-Code. Escape fand über 400 offengelegte Geheimnisse ^[3][6].
4. Fehlende oder schwache Anmeldeprüfungen: private Seiten oder API-Routen, die ohne Sitzung antworten. Authentifizierungsfehler trafen 51,50 % der geprüften Apps ^[4].
5. Injection: Nutzereingaben gelangen ungeprüft in Datenbankabfragen oder HTML; gefunden in 54,00 % der geprüften Apps ^[4].
6. Beschreibbare Tabellen: Regeln, die Besuchern das Einfügen oder Ändern von Daten erlauben, nicht nur das Lesen. Im CVE-Fall fügte eine Anfrage ohne Anmelde-Token einen als "bezahlt" markierten Datensatz ein und übersprang den Zahlungsschritt ^[1].
7. Geschwätzige Antworten: APIs, die ganze Nutzerdatensätze, E-Mails oder Tokens liefern, obwohl die Seite nur einen Namen braucht. Escape zählte 175 Fälle offengelegter persönlicher Daten ^[3].
8. Riskanter Agentenzugriff: Ein Coding-Agent mit Produktionszugangsdaten kann echten Schaden anrichten; im Juli 2025 löschte ein Agent während eines Code-Freeze eine Live-Datenbank ^[10].

Die Lücken 1 bis 4 decken das meiste ab, was Außenstehende ausnutzen, testen Sie sie also zuerst.

Wie teste ich meine Vibe-Coding-App auf diese Lücken?

Nutzen Sie die App wie ein Angreifer: als Fremder, als zweiter Nutzer und indem Sie lesen, was der Browser empfängt ^[1][4][5]. Keiner dieser Schritte erfordert Spezialwerkzeuge.

1. Legen Sie zwei Testkonten an. Erstellen Sie mit Konto A einen Datensatz, kopieren Sie dessen Adresse oder ID, melden Sie sich als Konto B an und versuchen Sie, ihn zu öffnen, zu bearbeiten und zu löschen. Klappt das, ist die Zugriffskontrolle defekt ^[4].
2. Wiederholen Sie es abgemeldet. Öffnen Sie dieselben Adressen in einem privaten Fenster ohne Sitzung. Im CVE-Fall genügte das Entfernen des Anmelde-Headers, um jede Prüfung zu umgehen ^[1].
3. Beobachten Sie den Netzwerk-Tab. Sehen Sie sich in den Entwicklertools des Browsers jede Anfrage der Seite an und was zurückkommt. Antworten sollten nur enthalten, was dieser Bildschirm braucht, nie E-Mails oder Tokens anderer Nutzer ^[3].
4. Durchsuchen Sie den Seitencode nach Schlüsseln. Suchen Sie nach Zeichenfolgen, die mit sb_secret_ beginnen, nach der Bezeichnung service_role oder nach Anbieterschlüsseln etwa für Zahlungen oder KI. Ein Publishable Key ist normal; ein Secret Key ist ein Notfall ^[6].
5. Prüfen Sie die Regeln jeder Tabelle. Bestätigen Sie im Datenbank-Dashboard, dass Row Level Security für jede Tabelle aktiv ist, und lesen Sie jede Regel in einfachen Worten: Wer darf lesen, wer darf schreiben ^[7].
6. Probieren Sie fehlerhafte Eingaben. Fügen Sie sehr langen Text, Anführungszeichen und HTML-Tags in jedes Formular ein und prüfen Sie, ob die App abstürzt oder sie als Code darstellt ^[4].

Testen Sie nur Apps, die Ihnen gehören oder die Sie testen dürfen. Untersuchen Sie fremde Apps nicht ohne schriftliche Erlaubnis.

Wie behebe ich offene Supabase-Regeln und geleakte Schlüssel?

Aktivieren Sie Row Level Security für jede Tabelle, schreiben Sie enge Regeln, halten Sie geheime Schlüssel auf dem Server und ersetzen Sie jeden geleakten Schlüssel ^[6][7][8].

• Row Level Security überall aktivieren. Laut Supabase-Leitfaden sollte sie bei jeder Tabelle in einem öffentlich erreichbaren Schema aktiviert sein ^[7]. Danach erreicht der öffentliche Schlüssel nichts, bis Sie Regeln hinzufügen ^[7].
• Standardrechte entfernen. Bei Projekten, die sie noch standardmäßig vergeben, startet eine neue öffentliche Tabelle mit allen Rechten, die bereits den Rollen für abgemeldete (anon) und angemeldete (authenticated) Nutzer gewährt sind, und Regeln nehmen diese Rechte nicht zurück ^[7]. Entziehen Sie sie und vergeben Sie nur zurück, was jede Rolle braucht ^[7].
• Regeln pro Nutzer schreiben. Eine Regel für eine private Tabelle sollte zur ID des angemeldeten Nutzers passen, statt einfach jeden Angemeldeten zuzulassen. Vermeiden Sie Regeln, die bei sensiblen Tabellen immer wahr sind ^[2].
• Geheime Schlüssel serverseitig halten. Der Publishable Key von Supabase ist im Browser nur deshalb sicher, weil Zeilenregeln ihn begrenzen; Secret- und service_role-Schlüssel umgehen jede Regel und gehören in Servercode oder sichere Umgebungseinstellungen ^[6].
• Geleakte Schlüssel austauschen. Ist ein geheimer Schlüssel je in den Browser oder ein öffentliches Code-Repository gelangt, tauschen Sie ihn aus und deaktivieren Sie den geleakten, wie es der Schlüssel-Leitfaden von Supabase rät ^[6].

Nach der Dokumentation von Supabase (Stand 15. November 2026) werden die alten anon- und service_role-Schlüssel bis Ende 2026 zugunsten von Publishable und Secret Keys abgeschafft ^[8]. Die neuen Secret Keys liefern in einem Browser einen Fehler (HTTP 401), ein geleakter Schlüssel kann aber weiterhin aus anderen Tools genutzt werden ^[6][8]. Der Umstieg jetzt ist ein guter Anlass, jeden Schlüssel einer App zu prüfen.

Erkennen eingebaute Sicherheitsscanner alles?

Nein: Plattform-Scanner helfen, aber mehrere Studien zeigen, dass sie die wichtigsten Regeln übersehen ^[1][2][5].

2025 stellten die Forscher hinter CVE-2025-48757 fest, dass der Scanner von Lovable nur prüfte, ob eine Zeilenregel existierte, nicht ob sie korrekt war ^[1]. Ihr Advisory ergänzt, dass die Veröffentlichungsprüfung von Lovable Tabellen ohne Regeln markiert, aber nicht zeigt, ob die Regeln streng genug sind ^[2]. Eine offene Regel besteht eine solche Prüfung.

Die ACM-Studie belegt das mit Zahlen: Ein moderater Anteil offener Regeln, 6,3 % über sechs Tools, ließ dennoch 56,9 % der Repositorys mit mindestens einer offenen Tabelle zurück, weil eine offene Regel genügt ^[5]. Die Autoren veröffentlichten ein kostenloses Prüfwerkzeug, das solche Regeln vor dem Commit markiert ^[5].

Nutzen Sie Scanner als ersten Filter und machen Sie die Tests mit zwei Konten und im abgemeldeten Zustand selbst. Die Tabelle unten fasst die Zahlen zusammen.

Ist es sicher, Apps zu nutzen, die andere per Vibe Coding gebaut haben?

Seien Sie vorsichtig bei allem, was persönliche, Gesundheits- oder Zahlungsdaten verlangt, denn Nutzer sehen nicht, wie eine App sie schützt ^[3][4]. Escape fand unter den offengelegten Daten Krankenakten und IBANs (Kennungen von Bankkonten) ^[3].

Einige einfache Gewohnheiten senken das Risiko. Verwenden Sie für jede neue App ein eigenes Passwort, damit ein Leck nicht andere Konten öffnet; wie das geht, erklärt der Pouyam-Ratgeber Password Managers Explained: How They Work and Whether They Are Safe. Geben Sie nur die Daten an, die eine App braucht, und nutzen Sie lieber Zahlungsseiten bekannter Zahlungsanbieter als Formulare in der App.

Die Hauptverantwortung liegt bei den Entwicklern. Wer eine App veröffentlicht, die Daten anderer speichert, sollte die Prüfungen oben vor dem Start und nach jeder größeren Änderung durchführen, denn eine einzige neue Funktion kann eine geschlossene Lücke wieder öffnen ^[4][5].