Security: Der gefährliche Komfort von Vibe-Coding
Inhalt
Von außen wirkt alles fertig: Login, Formular, Dashboard, Datenbank. Doch genau diese fertige Oberfläche kann täuschen. Eine App kann funktionieren und trotzdem vertrauliche Daten offenlegen.
Das ist das zentrale Risiko von Vibe-Coding: Softwareentwicklung wandert aus dem Editor in den Chat, Nutzer beschreiben, was sie bauen wollen, KI-Systeme erzeugen daraus Code, Datenmodelle und Deployment-Anweisungen. Bei modernen Backend-Diensten wie Supabase hängt genau das stark an Rollen, Tabellenrechten und Row Level Security. Damit rückt die unsichtbare Schutzschicht hinter der Oberfläche in den Mittelpunkt.
RLS als unsichtbare Schutzschicht
Supabase, ein Backend-Dienst auf Basis von PostgreSQL, steht im Kern einer Recherche der Zeit (Paywall)(öffnet im neuen Fenster), für die die Zeit mit dem IT-Sicherheitsforscher Christopher Helm zusammengearbeitet hat. Demnach grenzte Helm die Untersuchung über öffentlich sichtbare technische Hinweise auf eine Supabase-Nutzung ein. Anschließend prüfte er eine Stichprobe von 670 deutschsprachigen Websites.
Das Ergebnis: In fast jeder zweiten Datenbank waren Zugriffe möglich. Die gefundenen Inhalte reichten von Gesundheitsdaten über Passwörter und Bewerbungsunterlagen bis zu Kundendaten und technischen Zeichnungen.
Technisch geht es vor allem um Row Level Security, kurz RLS. Supabase schreibt in der eigenen Dokumentation(öffnet im neuen Fenster), RLS müsse für Tabellen in einem exponierten Schema immer aktiviert sein. Für Tabellen aus dem Table Editor gilt das automatisch.
Wer Tabellen per SQL oder über andere Werkzeuge erzeugt, muss die Schutzschicht selbst setzen und Rollen passend beschränken. Die technische Ursache liegt damit nicht nur in einer einzelnen Fehlkonfiguration, sondern im Zusammenspiel aus Tabellenrechten, Rollen und RLS-Policies.
Vom Fund zur Matrix
Helm beließ es nach den vorliegenden Unterlagen nicht bei einzelnen Funden. Er legte ein privates Arbeits-Repository an, das nach seiner Darstellung an Paul Copplestone, CEO und Mitgründer von Supabase, sowie an CISO Bil Harmer adressiert war.
Darin beschreibt Helm eine "Supabase security audit skill" und katalogisiert 61 mögliche Vektoren. Gemeint sind keine bestätigten Einzelfälle, sondern prüfbare Muster: unsichere Defaults, wiederkehrende Betreiberfehler, Fallen im Anwendungscode und neuere Angriffsflächen etwa bei Realtime, pg_net, Vault, Rate Limits oder Backups.
Gerade diese Trennung ist wichtig. Das Repository versteht sich nicht als Liste konkreter Datenlecks und auch nicht als pauschaler Schwachstellenbericht gegen Supabase. Ob ein Projekt betroffen ist, soll erst eine Verifikationsprobe am jeweiligen Zielsystem zeigen.
Damit wird aus der Recherche mehr als eine Sammlung einzelner Fehlkonfigurationen. Sie beschreibt ein wiederkehrendes Risikomuster: KI-generierte Projekte können funktionierende Anwendungen erzeugen, aber zugleich Sicherheitsannahmen übernehmen, die im produktiven Betrieb nicht tragen. Die eigentliche Frage lautet deshalb nicht nur, wer den Code schreibt, sondern auch, wer die Sicherheitsarchitektur prüft.
- Anzeige Hier geht es zu Künstliche Intelligenz: Wissensverarbeitung bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.