Vibe Coding Sicherheitsrisiken: 5 nachgestellte Lücken

Ich bin Denys, Full-Stack- und KI-Entwickler. Ich repariere Apps, die mit Lovable, Bolt, Cursor oder Claude Code gebaut wurden, und die meisten laufen auf Supabase. Dieser Artikel sammelt, was die veröffentlichte Forschung zur Sicherheit von vibe coding sagt, und was ich gesehen habe, als ich die häufigen Fehler absichtlich nachgebaut habe.

Welche Sicherheitsrisiken hat vibe coding?

Das Hauptrisiko ist fehlerhafte Zugriffskontrolle: Daten, die jeder Besucher lesen oder ändern kann, weil die Regel, die ihn aufhalten sollte, fehlt, zu locker ist oder umgangen wird. Danach kommen Injection und schwache Authentifizierung. Drei unabhängige Studien zeigen in dieselbe Richtung:

Studie	Was getestet wurde	Was sie fand
Deng, Fan und Meng, arXiv 2606.23130, Juni 2026	200 produktive Apps, gebaut mit Claude Code und Lovable, von Hand und von Agenten geprüft	182 von 200 Apps (91 %) hatten mindestens eine Schwachstelle; 65,77 % der 1.186 Befunde waren Critical oder High; fehlerhafte Zugriffskontrolle war die größte Kategorie, in 64 % der Apps
Escape, Oktober 2025	5.600 öffentliche Apps von Lovable, Base44, Create.xyz und anderen, passiver Scan	Über 2.000 Schwachstellen mit hoher Auswirkung, über 400 offengelegte Secrets, 175 Fälle offengelegter personenbezogener Daten; Hauptursache waren falsch konfigurierte Berechtigungen, vor allem Supabase RLS
Veracode GenAI Code Security Report, 2025 und 2026	80 Programmieraufgaben für über 100 Modelle	Nur 55 % der Aufgaben ergaben 2025 sicheren Code; die durchschnittliche Erfolgsquote lag 2026 bei 56 %, unabhängig von Modellgröße und Jahr

Die Studien messen Verschiedenes, die Prozentwerte ergeben also keine gemeinsame Zahl. Gemeinsam ist ihnen das Muster: Der Code funktioniert, und die Lücken liegen an der Vertrauensgrenze.

Welche Lücken habe ich nachgestellt?

Ich habe auf einem lokalen Supabase-Stack (CLI 2.109.1, Postgres 17.6, PostgREST 14.14) eine Tabelle orders mit drei Zeilen erfundener Kunden angelegt. Dann habe ich die Data API so aufgerufen wie ein Browser, mit dem Publishable Key, den jedes Supabase-Frontend ausliefert, und jeweils nur eine Sache geändert.

Aufbau	Was der öffentliche Key bekam	Warum
Tabelle ohne RLS	Alle 3 Zeilen, und ein Insert kam mit 201 Created zurück	Die Standard-Grants lassen anon lesen und schreiben, und nichts filtert Zeilen
RLS an, keine Policy	[], eine leere Liste	RLS ohne Policy verweigert anon und authenticated alles
Policy using (true)	Alle 3 Zeilen	Die Policy existiert, die Tabelle wirkt also geschützt, aber sie erlaubt jede Zeile
View über die geschützte Tabelle	Alle 3 Zeilen	Eine View läuft mit den Rechten ihres Besitzers, außer sie hat security_invoker = true; damit kommt []
Secret Key im Frontend-Code	Alle 3 Zeilen	Der Secret Key gehört zu service_role, und die hat BYPASSRLS

Die zweite Zeile ist der gefährliche Moment. RLS ist an, und die App zeigt eine leere Liste, sie wirkt also kaputt. Der schnellste Prompt, der das “behebt”, ist eine Policy, die alles erlaubt, also die dritte Zeile. Diese Schleife, Fehler und dann eine Korrektur, die den Zugriff erweitert, ist das Muster, das ich in vibe-codierten Apps am häufigsten sehe, und deshalb sagt “RLS ist an” allein wenig.

Warum scheitert KI-Code an der Zugriffskontrolle?

Ein Agent wird für Code belohnt, der läuft. Eine leere Liste oder ein 401 sieht aus wie ein Bug, und die Korrektur, die ihn verschwinden lässt, ist oft die, die den Zugriff öffnet. Die arXiv-Studie führt ihre 1.186 Befunde auf acht wiederkehrende Fehlermuster zurück, gruppiert als Gedächtnis-, Ziel- und Wissensdefekte der Agenten, und fand, dass besseres Prompting die Zahl der Lücken senkte, sie aber nicht beseitigte.

Der zweite Grund ist die Architektur. Eine Lovable- oder Bolt-App hat meist kein eigenes Backend: Der Browser spricht über die Data API direkt mit der Datenbank. Jede Regel, die Kundendaten schützt, muss in Postgres liegen, als Grants, Policies und Funktionen, und nichts davon ist in der App-Vorschau sichtbar, in der Sie als Besitzer angemeldet sind. Supabase ändert hier einen Standard: Ab dem 30. Oktober 2026 bekommen neue Tabellen in bestehenden Projekten nicht mehr automatisch Grants für die Data API. Auf meinem Stack antwortete eine Tabelle ohne Grant mit 42501 permission denied und einem Hinweis, der den fehlenden GRANT nennt. Das stoppt die erste Zeile der Tabelle oben für neue Tabellen, aber nicht die anderen vier und nicht Tabellen, die schon existieren.

Was geht außerhalb der Datenbank noch schief?

Dieselben Studien nennen Risiken, die mit RLS nichts zu tun haben:

• Secrets im Bundle. Escape fand über 400 offengelegte Secrets, darunter OpenAI-Keys und Admin-Keys für Zahlungen. Alles, was an den Browser ausgeliefert wird, ist öffentlich.
• Routen-Guards nur in React. Eine Seite, die abgemeldete Nutzer umleitet, hat trotzdem eine API dahinter, die jedem antwortet.
• Rate Limits, die nie greifen. In einem gehosteten Supabase-Projekt, das ich geprüft habe, wurde ein Zähler im Speicher einer Edge Function bei jeder Anfrage zurückgesetzt. Das habe ich in meiner Sicherheits-Checkliste für Lovable-Apps beschrieben.
• Alte Bibliotheken. Escape zählte 254 verwundbare JavaScript-Bibliotheksinstanzen in öffentlichen Assets, oft aus Vorlagen übernommen.

Wie prüfen Sie eine vibe-codierte App?

1. Öffnen Sie die App, dann DevTools → Network, und suchen Sie Anfragen an /rest/v1/. Kopieren Sie eine als cURL, entfernen Sie den Authorization-Header, behalten Sie den apikey und führen Sie sie aus. Kommen Daten zurück, bekommt sie jeder.
2. Durchsuchen Sie das gebaute JavaScript nach sb_secret_ und service_role. Ein Treffer ist ein Key, den Sie heute rotieren.
3. Führen Sie den kostenlosen Supabase-Sicherheitscheck aus. Er liest den Katalog des Projekts und meldet unter seinen 46 Regeln unter anderem “RLS bei exponierten Tabellen deaktiviert”, “Policies, die jede Zeile erlauben”, “Views, die RLS umgehen” und “Standardrechte, die neue Objekte für die API öffnen”: die ersten vier Zeilen der Tabelle oben.
4. Testen Sie mit zwei Nutzern in zwei Firmen, dem einen Test, den ein Scanner nicht für Sie machen kann. Wie ich das mache, steht in der Lovable-Checkliste, und Supabase RLS testen zeigt die Methode an einer Produktions-App mit Rechte-Seite.

curl 'https://<project>.supabase.co/rest/v1/orders?select=*' \
  -H 'apikey: <the publishable key from your page>'

Was das nicht zeigt

Meine Nachstellung ist eine Tabelle auf einem lokalen Stack, gebaut, um jeden Mechanismus zu zeigen, kein Scan echter Apps. Die Häufigkeitszahlen stammen aus den drei Studien, jeweils mit eigener Stichprobe und Methode, oben verlinkt. Und ein sauberes Ergebnis bei diesen fünf Prüfungen macht eine App nicht sicher: Logikfehler, etwa ein Guard, der einen fehlenden Wert durchlässt, brauchen eigene Tests. Einer davon steht in einem NULL, das eine Berechtigungsprüfung übersprang.