16.000 offene Supabase-Datenbanken: Wenn Vibe Coding plötzlich echte Daten ins Netz stellt

Manchmal braucht es keinen Zero-Day, keinen ausgefeilten Exploit und nicht einmal besonders viel technisches Wissen, um an Daten zu gelangen, die eigentlich nicht öffentlich sein sollten.

Ich habe das selbst erlebt.

Bei einem deutschen Onlineshop stieß ich im öffentlich ausgelieferten Frontend auf einen API-Schlüssel. Über die damit angesprochene Schnittstelle waren Daten erreichbar, die offensichtlich nicht für die öffentliche Darstellung gedacht waren.

Dafür war kein Einbruch in einen Server nötig. Kein komplizierter Angriff. Kein stundenlanges Reverse Engineering.

Man musste nur genauer hinsehen.

Genau deshalb ist eine aktuelle Untersuchung der Sicherheitsfirma UpGuard bemerkenswert. Nach Recherchen von TechCrunch fand das Unternehmen rund 16.000 auf Supabase gehostete Datenbanken, bei denen zumindest Teile der gespeicherten Informationen öffentlich erreichbar waren.

Darunter befanden sich Namen, Adressen, Telefonnummern und Passwörter. In einer kleineren Zahl von Fällen sollen auch Authentifizierungs-Tokens offengelegen haben.

Das eigentliche Problem ist dabei größer als Supabase.

Eine App bauen ist plötzlich leichter als eine App absichern

Supabase ist in den vergangenen Jahren zu einem beliebten Backend für moderne Webanwendungen geworden. Die Plattform kombiniert unter anderem PostgreSQL, Authentifizierung, APIs, Storage und weitere Backend-Funktionen.

Gerade beim Vibe Coding passt dieses Modell perfekt.

Ein Entwickler oder auch ein technisch interessierter Einsteiger kann heute einem KI-Werkzeug sagen:

Baue mir eine Benutzerverwaltung. Erstelle eine Datenbank. Speichere Kundendaten. Füge einen Login hinzu. Erstelle ein Dashboard und verbinde alles mit Supabase.

Wenige Stunden später kann daraus eine funktionierende Anwendung entstehen.

Der Login funktioniert.

Die Daten werden gespeichert.

Das Dashboard sieht gut aus.

Die App läuft.

Damit entsteht allerdings schnell ein gefährlicher Eindruck: Wenn alles funktioniert, muss es auch richtig konfiguriert sein.

Das ist nicht dasselbe.

Ein sichtbarer API-Key ist nicht automatisch eine Sicherheitslücke

An dieser Stelle ist eine wichtige Unterscheidung nötig.

Ein API-Schlüssel im öffentlich ausgelieferten JavaScript einer Anwendung ist nicht automatisch ein Sicherheitsproblem. Einige Plattformen sehen ausdrücklich Schlüssel vor, die auf der Client-Seite verwendet werden dürfen.

Auch bei Supabase gibt es öffentliche Schlüssel für Frontend-Anwendungen.

Die Sicherheit entsteht in diesem Fall nicht dadurch, dass niemand den Schlüssel kennt.

Sie entsteht dadurch, dass der Schlüssel nur genau die Dinge tun darf, die ein Besucher oder angemeldeter Benutzer tun soll.

Dafür verwendet Supabase unter anderem Row Level Security, kurz RLS. Damit lässt sich auf Datenbankebene festlegen, welche Datensätze ein bestimmter Benutzer lesen, verändern oder löschen darf.

Ein öffentlich sichtbarer Schlüssel kann deshalb vollkommen normal sein.

Ein öffentlich sichtbarer Schlüssel, mit dem anschließend beliebige Daten einer Anwendung ausgelesen werden können, ist es nicht.

Gefährlich wird es bei falschen Berechtigungen

Genau hier liegt eine der Schwachstellen moderner KI-gestützter Entwicklung.

Ein Entwickler sieht möglicherweise nur, dass seine Anwendung funktioniert. Der angemeldete Nutzer bekommt seine Daten angezeigt und ein nicht angemeldeter Besucher landet auf der Login-Seite.

Das bedeutet aber noch lange nicht, dass die Datenbank selbst dieselben Regeln durchsetzt.

Eine Benutzeroberfläche kann einen Zugriff verhindern, während die dahinterliegende API weiterhin Daten ausliefert.

Das ist ein entscheidender Unterschied.

Der Browser zeigt vielleicht keinen Button.

Die API kennt diesen Button aber gar nicht.

Sie kennt nur Berechtigungen.

Sind diese falsch gesetzt, können Daten unter Umständen direkt über die Schnittstelle abgefragt werden.

Noch gefährlicher sind echte Secret Keys

Neben öffentlichen Client-Schlüsseln existieren bei Backend-Plattformen auch Schlüssel mit deutlich weiterreichenden Rechten.

Solche Secret- oder Service-Schlüssel gehören ausschließlich auf kontrollierte Server.

Sie dürfen nicht im Frontend, in öffentlich erreichbaren JavaScript-Dateien oder in frei zugänglichen Konfigurationsdateien landen.

Passiert es trotzdem, kann aus einem simplen Konfigurationsfehler sehr schnell ein ernstes Sicherheitsproblem werden.

Das klingt selbstverständlich.

Aber genau hier trifft klassische IT-Sicherheit auf eine vollkommen neue Form der Softwareentwicklung.

Vibe Coding verändert, wer Software bauen kann

Vor wenigen Jahren musste jemand, der eine Anwendung mit Datenbank, Authentifizierung und API entwickeln wollte, zwangsläufig viele technische Details verstehen.

Man musste wissen, wie HTTP funktioniert, wie eine Datenbank angebunden wird, wie Benutzer authentifiziert werden und wie Zugriffsrechte aussehen.

Heute übernimmt eine KI einen großen Teil davon.

Das ist eine enorme Verbesserung.

Aber es entsteht gleichzeitig eine neue Klasse von Entwicklern, die funktionierende Systeme betreiben können, ohne jede darunterliegende Komponente vollständig verstanden zu haben.

Die KI schreibt SQL.

Sie erzeugt API-Aufrufe.

Sie baut Login-Seiten.

Sie verbindet Frontend und Backend.

Was dabei leicht verloren geht, ist das Verständnis dafür, warum etwas sicher ist.

16.000 Datenbanken zeigen die Größenordnung

Die von UpGuard gefundenen Fälle zeigen, dass es sich längst nicht mehr nur um ein theoretisches Risiko handelt.

Nach Angaben von TechCrunch fanden die Sicherheitsforscher unter anderem private Unterhaltungen einer Plattform für Erwachsenen-Unterhaltung, Tausende Kennzeichen eines US-Valetdienstes und Kontaktdaten von Menschen, die einen Einwanderungs- und Umzugsdienst genutzt hatten.

Eine weitere Datenbank soll zu einem afrikanischen Konsulat in Frankreich gehört haben.

Besonders bemerkenswert ist ein weiterer Fall: UpGuard fand Daten eines virtuellen SIM-Dienstes, über den SMS mit Einmalcodes empfangen wurden. Solche Dienste können unter anderem verwendet werden, um Online-Konten zu verifizieren.

Damit geht es nicht um harmlose Testdatensätze.

Es geht um Informationen realer Menschen.

Supabase weist die Verantwortung nicht allein von sich

Supabase selbst betont, dass seine Projekte standardmäßig sicher eingerichtet seien.

CISO Bil Harmer erklärte gegenüber TechCrunch, Sicherheit sei eine gemeinsame Verantwortung von Plattform und Kunden. Supabase stelle sichere Grundeinstellungen und entsprechende Werkzeuge bereit, während Kunden darüber bestimmten, wie ihre Projekte letztlich konfiguriert würden.

Das ist eine wichtige Unterscheidung.

Nach den bisher veröffentlichten Informationen handelt es sich nicht um eine zentrale Schwachstelle, über die sich beliebige Supabase-Datenbanken knacken lassen.

Das Problem sind vielmehr einzelne Projekte, bei denen Zugriffsregeln oder Berechtigungen offenbar nicht ausreichend eingerichtet wurden.

Supabase ist damit gleichzeitig Teil der Geschichte und nicht ihr eigentlicher Kern.

Fehlkonfigurationen gab es schon immer

Offene Datenbanken sind kein neues Phänomen.

Schon lange vor ChatGPT gab es frei erreichbare MongoDB-Instanzen, schlecht konfigurierte Elasticsearch-Server und Cloud-Speicher, in denen sensible Dateien ohne ausreichenden Zugriffsschutz lagen.

Neu ist etwas anderes.

Die Geschwindigkeit.

KI kann heute innerhalb weniger Minuten Code erzeugen, für den früher Stunden oder Tage notwendig waren.

Das bedeutet auch: Fehler können sich schneller verbreiten.

Wenn ein Entwickler ein Sicherheitskonzept falsch versteht, betrifft das nicht mehr zwangsläufig nur eine Anwendung, die er über Wochen entwickelt hat.

Mit KI kann derselbe Fehler innerhalb kurzer Zeit in mehreren Projekten landen.

KI skaliert nicht nur Produktivität

Genau darin liegt möglicherweise eine der größten unterschätzten Nebenwirkungen des Vibe-Coding-Booms.

Wir sprechen meistens darüber, wie stark KI die Produktivität von Entwicklern steigert.

Ein Entwickler kann plötzlich die Arbeit von mehreren Menschen erledigen. Ein Gründer kann ohne großes Team einen Prototyp bauen. Menschen ohne klassische Programmierausbildung können eigene Anwendungen entwickeln.

Aber Produktivität ist nicht das Einzige, was skaliert.

Auch Fehler skalieren.

Eine falsch gesetzte Datenbankregel wird durch KI nicht weniger falsch.

Sie kann nur schneller erstellt, kopiert und produktiv eingesetzt werden.

Das Problem ist der Moment, in dem alles funktioniert

Besonders gefährlich ist dabei, dass viele Sicherheitsprobleme im normalen Betrieb überhaupt nicht auffallen.

Der Entwickler startet seine Anwendung.

Der Login funktioniert.

Er meldet sich an.

Seine Datensätze erscheinen.

Er meldet sich wieder ab.

Die Datensätze verschwinden.

Test bestanden.

Nur hat damit niemand geprüft, was passiert, wenn jemand die Benutzeroberfläche komplett ignoriert und direkt mit der dahinterliegenden Schnittstelle spricht.

Genau dieser Perspektivwechsel gehört eigentlich zu einem Sicherheitstest.

„Es funktioniert“ ist kein Sicherheitstest

Vibe Coding wird nicht wieder verschwinden.

Die Vorteile sind zu groß.

Softwareentwicklung wird schneller und zugänglicher, und viele Projekte, die früher nie umgesetzt worden wären, können heute überhaupt erst entstehen.

Aber dieselben Werkzeuge müssen lernen, Sicherheit nicht als nachträgliche Aufgabe zu behandeln.

Eine KI sollte nicht nur fragen, ob eine Datenbankabfrage funktioniert.

Sie sollte auch prüfen, wer diese Abfrage ausführen darf.

Sie sollte nicht nur einen Login erstellen.

Sie sollte testen, ob sich die dahinterliegenden Daten tatsächlich nur mit den vorgesehenen Rechten abrufen lassen.

Und wer mit KI Software entwickelt, muss sich an eine zweite Frage gewöhnen.

Nicht nur:

„Funktioniert meine App?“

Sondern:

„Was kann jemand sehen, der sich nicht so verhält, wie ich es vorgesehen habe?“

Die rund 16.000 von UpGuard gefundenen Datenbanken zeigen ziemlich deutlich, warum diese zweite Frage inzwischen mindestens genauso wichtig ist wie die erste.