Vibe-Coding-Lecks: 670 Websites, halbe Datenbanken offen

Der Berliner IT-Sicherheitsforscher Christopher Helm hat zusammen mit der ZEIT 670 deutschsprachige Websites geprüft, die Supabase als Backend nutzen. Ergebnis: fast die Hälfte der Datenbanken stand frei zugänglich im Netz. Offen lagen Gesundheitsdaten, Passwörter, Bewerbungsunterlagen, Produktionspläne und Kundenadressen.

Was konkret gefunden wurde

Bei einem deutschen Industrieanlagenbauer waren rund 700.000 Datensätze ungeschützt. Bei einem US-Anbieter für IT-Sicherheitsschulungen für Behörden lagen private Daten von FBI-Mitarbeitern offen. Helm hat über 250 betroffene Unternehmen informiert. Zwei haben geantwortet.

Die technische Ursache ist nicht exotisch: fehlende Row Level Security (RLS) und unsichere Default-Berechtigungen für die anon- und authenticated-Rollen, über mehrere Zugriffswege (REST, GraphQL, Realtime, Storage, Edge Functions). Das ist seit Jahren als typisches Supabase-Anti-Pattern dokumentiert. Neu ist nur, wer die Konfigurationen jetzt anlegt.

Wo die KI-Tools ins Spiel kommen

Lovable, Cursor und Claude Code generieren Websites mit Backend-Anbindung in Minuten. Sie legen Tabellen an, schalten Authentifizierung ein, deployen das Frontend. Was sie typischerweise nicht tun, ohne explizite Anweisung: RLS aktivieren, Berechtigungen einschränken, Schlüssel sauber trennen. Helm dokumentiert in seinem Blogpost einen Test mit Claude Opus 4.6, der in neun Stunden für unter 200 Euro 711 Arbeitsergebnisse erzeugt hat. Geschwindigkeit ist also nicht das Problem.

Das Problem ist die Kombination aus zwei Dingen: KI-Tools übernehmen Defaults von Backend-Diensten unkritisch, und Vibe-Coder ohne Programmierkenntnisse können diese Konfigurationen nicht prüfen, weil sie nicht lesen können, was sie da bauen. Der KI-Agent ist dabei nicht Schuld an der Lücke, er ist nur ein sehr produktiver Verteiler einer schon vorher unsicheren Default-Konfiguration.

Was Supabase macht

Supabase hat innerhalb weniger Wochen reagiert. RLS-Aktivierung als Default in Studio, neue Lint-Rules in Splinter (dem internen Konfigurations-Linter), ein RLS-Tester-Feature, neue Key-Management-Standards. Bis Ende Mai 2026 sollen die Default-Einstellungen für neu angelegte Projekte sicher sein. Bestehende Projekte werden nicht rückwirkend abgesichert, das müssen die Betreiber selbst machen.

Wichtig zur Einordnung: Supabase hatte schon vorher Security Advisors im Dashboard, die auf unsichere Konfigurationen hinweisen. Wer die ignoriert oder gar nicht öffnet, weil das Tool im Browser läuft und der KI-Agent das Deployment abschließt, sieht die Warnungen nicht.

Was IT-Teams jetzt tun sollten

Wer im Team oder bei Kunden Vibe-Coding-Stacks im Einsatz hat, sollte heute drei Sachen prüfen.

Erstens: Inventur. Welche Mitarbeitenden bauen mit Lovable, Cursor, Bolt, Claude Code Apps mit Backend-Anbindung? Bei wie vielen davon liegt die Datenhaltung in Supabase, Firebase, Planetscale oder vergleichbaren Backends? In den meisten Organisationen ist die Antwort "deutlich mehr als IT denkt".

Zweitens: Helms Supabase Security Check auf alle bekannten eigenen und Kunden-Projekte anwenden. Das Tool zeigt unmittelbar, ob eine Datenbank über die anonyme Rolle Daten preisgibt. Bei Treffern: RLS aktivieren, Policies pro Tabelle definieren, Service-Role-Keys aus dem Frontend entfernen, Keys rotieren. Helm rechnet mit zwei Stunden bis einem Tag pro Projekt.

Drittens: Policy. Vibe-Coding für Prototypen ist legitim. Vibe-Coding für produktive Apps mit echten Nutzerdaten braucht ein Code-Review und einen Security-Check vor dem Go-live. Diese Regel formal aufschreiben und in Onboarding und Tooling-Dokumentation verankern, sonst landet die nächste FBI-Mitarbeiterliste auf einer dritten Lovable-Site.

Mehr zum Hintergrund im KI-Tools-sicher-nutzen-Artikel und im DSGVO-KI-Compliance-Artikel.

Bildnachweise

• Bunter Code auf Monitor: Foto von Markus Spiske auf Unsplash