Supabase-Datenexposition setzt Sicherheitsversprechen von Vibe-Coded Apps unter Druck
Supabase steht unter Beobachtung, nachdem Forschende 16.326 Datenbanken mit öffentlich lesbaren Tabellen identifiziert haben, obwohl die Plattform ihre Projekte als standardmäßig sicher beschreibt. Die Erkenntnisse zur Supabase-Datenexposition verbinden ein bekanntes Cloud-Sicherheitsproblem mit einer neueren Risikoquelle: Apps, die mit KI-Coding-Tools schnell zusammengestellt werden.
UpGuard fand in mehr als der Hälfte der exponierten Datenbanken Hinweise auf personenbezogene Daten. Zu den betroffenen Datensätzen gehörten Berichten zufolge Namen, Adressen, Telefonnummern, Geburtsdaten, Passwörter, Authentifizierungstokens, private Nachrichten, Kennzeichen und Einwanderungsinformationen.
Es handelte sich nicht um einen einzelnen Einbruch in die internen Systeme von Supabase. Die Belege deuten vielmehr auf Kundendatenbanken hin, die durch fehlende oder unzureichende Zugriffskontrollen offengelegt wurden. Dieser Unterschied ist wichtig, macht das Ausmaß aber nicht weniger besorgniserregend.
Der Bericht macht aus einem technischen Konfigurationsfehler einen Test für das Vibe-Coding-Modell. KI-Assistenten können innerhalb von Minuten eine funktionierende Oberfläche erzeugen und mit einer gehosteten Datenbank verbinden. Sie stellen jedoch nicht zuverlässig sicher, dass jeder Nutzer, jede Tabelle, jede Rolle und jeder Vorgang die korrekte Autorisierungsrichtlinie erhält.
Was die Untersuchung zur Supabase-Datenexposition ergab
Die zentrale Erkenntnis von UpGuard betrifft nicht eine einzelne ungewöhnlich nachlässige App, sondern Tausende unabhängig entwickelter Projekte, die ähnliche Sicherheitsfehler wiederholen.
Für seine Untersuchung im September 2026 sammelte UpGuard etwa 300.000 einzigartige Domains, die Anzeichen für die Nutzung von Supabase zeigten. Die Forschenden nutzten Daten von BuiltWith und dem Chrome User Experience Report, um relevante Websites zu identifizieren.
Anschließend prüften sie, ob jedes Projekt eine Tabelle namens users offenlegte. Dieser gebräuchliche Tabellenname bot den Forschenden einen einheitlichen Ausgangspunkt, ohne dass sie das Datenbankdesign jeder Anwendung vorher kennen mussten.
Der Test führte zu mehreren möglichen Antworten. Eine sichere oder inaktive Datenbank gab keine zugänglichen Daten zurück. Einige Datenbanken legten über einen Fehlerhinweis eine andere zugängliche Tabelle offen. Andere lieferten eine Seite mit Datensätzen zurück.
Innerhalb dieser Kandidatenmenge identifizierte UpGuard 16.326 Datenbanken mit lesbaren Tabellen. Mehr als die Hälfte enthielt laut den Untersuchungen zur Datenexposition des Unternehmens Schemafelder, die auf irgendeine Form personenbezogener Daten hindeuteten.
Die Forschenden analysierten hauptsächlich Tabellenschemata, statt jeden verfügbaren Datensatz herunterzuladen. Ein Schema legt Spaltennamen und Datentypen offen, die darauf hindeuten können, ob eine Tabelle E-Mail-Adressen, Passwörter, Telefonnummern oder Zahlungsinformationen enthält.
Dieser Ansatz verringerte unnötige Zugriffe auf personenbezogene Datensätze. Er bedeutet zugleich, dass die Zahl von 16.326 nicht belegt, dass jede Datenbank sensible Informationen enthielt oder dass Angreifer die verfügbaren Daten zuvor kopiert hatten.
UpGuard untersuchte ausgewählte Fälle, bei denen die Metadaten auf eine erhebliche Exposition hindeuteten. Die Beispiele zeigen, wie ein Konfigurationsfehler von technischer Schuld zu direktem persönlichen Schaden führen kann.
Ein indischer Streamingdienst für Erwachsene legte eine Tabelle mit 65.467 Personen offen. Die Felder umfassten Berichten zufolge Identitätsdokumente, Adressen, Geburtsdaten, Finanzkonten und teilweise staatliche Identifikationsnummern. Eine weitere Tabelle enthielt mehr als 100.000 private Nachrichten mit Content Creators.
Ein Anbieter virtueller SIM-Karten auf den Philippinen legte Informationen zu mehr als 2.000 Nutzern und über 100.000 Textnachrichten offen. Die meisten Nachrichten enthielten Einmalpasscodes, doch die Stichprobe umfasste auch Tausende gewöhnlicher Kommunikationen zwischen Fahrern und Fahrgästen von Fahrdiensten.
Ein US-amerikanischer Valet-Service legte Datensätze zu mehr als 100.000 Kunden offen. Seine Datenbank enthielt rund 78.000 Kennzeichen, etwa 43.000 E-Mail-Adressen, Besuchsverläufe, Informationen zu Trinkgeldern und Freitextnotizen.
Die Forschenden fanden außerdem eine Datenbank eines afrikanischen Regierungskonsulats mit 25.000 Datensätzen. Einige Einträge identifizerten die Notunterbringungsorte von Menschen aus einer potenziell vulnerablen Bevölkerungsgruppe.
Ein kanadischer Einwanderungsdienst legte fast 5.000 Datensätze offen. Laut UpGuard enthielten 884 davon Passwörter im Klartext, was bedeutet, dass die Anwendung sowohl bei der Zugriffskontrolle als auch beim Umgang mit Passwörtern versagt hatte.
Diese Fälle stützen die übergeordnete Schlussfolgerung und legen zugleich unterschiedliche Ebenen des Versagens offen. Öffentlicher Tabellenzugriff öffnete die Tür, doch schwaches Anwendungsdesign machte die Inhalte gefährlicher.
Die ursprüngliche Berichterstattung besagte, dass die meisten betroffenen Datensätze offenbar mit den Vereinigten Staaten verbunden waren. UpGuard fand dennoch weltweit exponierte Projekte und beschrieb das Problem als global.
Die geografische Verbreitung ist relevant, weil Supabase als verbreitete Infrastruktur für kleine Anwendungen, neue Unternehmen und etablierte Organisationen dient. Ein wiederkehrendes Konfigurationsmuster kann daher nicht miteinander verbundene Nutzer in mehreren Branchen und Rechtsräumen betreffen.
Warum die Datenbank über das Web erreichbar war
Der öffentliche Schlüssel innerhalb einer Supabase-Anwendung ist nicht zwangsläufig die Schwachstelle. Entscheidend ist, welche Berechtigungen dieser Schlüssel hat.
Supabase stellt eine gehostete PostgreSQL-Datenbank neben Authentifizierung, Speicher und automatisch generierten Datenschnittstellen bereit. Eine Webanwendung kann über ihre Data API mit einem publishable key Anfragen stellen.
Entwickler gehen bisweilen davon aus, dass ein in Browser-Code auffindbarer Schlüssel beweist, dass er geleakt wurde. Supabase konzipiert publishable keys ausdrücklich für öffentliche Clients, einschließlich Websites und mobiler Anwendungen.
Der tatsächliche Schutz entsteht durch Grants und Row Level Security, meist als RLS abgekürzt. RLS ist eine PostgreSQL-Funktion, die Autorisierungsregeln innerhalb der Datenbank anwendet, bevor einzelne Zeilen zurückgegeben oder verändert werden.
Ein angemeldeter Nutzer könnte nur die Berechtigung erhalten, Datensätze mit der Kennung dieses Nutzers zu lesen. Ein nicht angemeldeter Besucher könnte überhaupt keinen Zugriff erhalten. Eine andere Richtlinie könnte allen erlauben, einen bewusst öffentlichen Produktkatalog zu lesen.
Die Sicherheitsdokumentation von Supabase besagt, dass Entwickler RLS für exponierte Tabellen aktivieren und Richtlinien nach dem Least-Privilege-Prinzip konfigurieren müssen. Der publishable key gilt nur dann als sicher, wenn diese Kontrollen den Zugriff korrekt einschränken.
Die Plattform stellt außerdem secret keys oder service-role keys für vertrauenswürdige Backend-Systeme bereit. Diese Schlüssel umgehen RLS und dürfen niemals in einem Browser, einer ausgelieferten Anwendung oder einem öffentlichen Repository erscheinen.
Diese Architektur schafft eine subtile Sicherheitsgrenze. Ein sichtbarer publishable key ist vorgesehen, bietet einem nicht authentifizierten Besucher jedoch auch einen Weg zu allem, auf das die Datenbank der Rolle anon Zugriff gewährt.
Wenn einer Tabelle RLS fehlt, sie zu weitreichende Grants hat oder eine Richtlinie jede Zeile erlaubt, kann ein Außenstehender sie über dieselbe Schnittstelle abfragen, die auch die legitime App nutzt. Ein ausgefeilter Angriff ist nicht erforderlich.
Die Forschenden von UpGuard fanden Zielprojekte, indem sie öffentlich ausgeliefertes JavaScript auf Supabase-Identifikatoren untersuchten. Danach konnten sie jede Datenbank fragen, ob eine gebräuchliche Tabelle über ihre öffentliche Schnittstelle verfügbar war.
Diese Technik ähnelt gewöhnlichem Anwendungsverhalten. Der Unterschied liegt darin, wer die Anfrage sendet und ob die Datenbank einen berechtigten Nutzer von jeder anderen Person im Internet unterscheiden kann.
Die ausführliche RLS-Anleitung von Supabase warnt, dass eine Tabelle in einem exponierten Schema lesbar oder beschreibbar sein kann, wenn RLS fehlt und die anfragende Rolle passende Grants hat. Sie empfiehlt, sowohl erlaubte als auch verweigerte Vorgänge für anonyme und authentifizierte Rollen zu testen.
Deshalb löst das bloße Rotieren eines publishable key nicht das zugrunde liegende Problem. Der neue Schlüssel bleibt über den Client abrufbar, während die fehlerhafte Datenbankrichtlinie weiterhin Zugriff gewährt.
Entwickler müssen stattdessen exponierte Schemata, Tabellen-Grants, den RLS-Status, Richtlinienbedingungen, Datenbank-Views und Serveranmeldedaten überprüfen. Außerdem benötigen sie Tests, die bestätigen, dass Nutzer die Datensätze anderer Nutzer weder lesen noch verändern können.
Views verdienen besondere Aufmerksamkeit. PostgreSQL-Views können Berechtigungen standardmäßig über ihren Eigentümer auswerten und dadurch möglicherweise Einschränkungen umgehen, die die zugrunde liegenden Tabellen schützen. Ein Projekt kann daher RLS überall aktivieren und dennoch Daten über einen unsicheren View offenlegen.
Dieselbe Unterscheidung gilt für die Authentifizierung. Jemanden zur Anmeldung zu verpflichten, hält Mandanten nicht automatisch voneinander getrennt. Jeder authentifizierte Nutzer kann weiterhin weitreichenden Zugriff erhalten, wenn die Richtlinie lediglich eine gültige Sitzung prüft.
Auf Schlüsselebene erklärt, ist Supabase-Sicherheit daher einfach. Öffentliche Clients benötigen eine öffentliche Kennung, während Datenbankrichtlinien die tatsächliche Grenze durchsetzen. Die Schwierigkeit besteht darin, die beabsichtigten Regeln einer Anwendung in vollständige, getestete Richtlinien zu übersetzen.
Vibe Coding macht aus einer Konfigurationslücke ein wiederkehrendes Muster
Sicherheitsrisiken durch Vibe Coding wachsen, wenn ein KI-Assistent auf ein sichtbares Ergebnis optimiert, während die Autorisierung für die Person, die ihn anleitet, unsichtbar bleibt.
Auch ein konventionelles Entwicklungsteam kann eine Datenbank falsch konfigurieren. Öffentliche Amazon-S3-Buckets, exponierte Elasticsearch-Cluster und geleakte Cloud-Anmeldedaten gab es lange, bevor generative KI in die Softwareentwicklung Einzug hielt.
Was sich durch Vibe Coding verändert, ist die Kombination aus Geschwindigkeit, Zugänglichkeit und begrenzter Überprüfung. Eine Person kann eine App in natürlicher Sprache anfordern, generierten Code akzeptieren, ein gehostetes Backend verbinden und sie bereitstellen, ohne die Vertrauensgrenzen zu verstehen.
Die Anwendung kann vollständig wirken, weil die Registrierung funktioniert, Datensätze korrekt gespeichert werden und Seiten laden. Diese Tests bestätigen die Funktionalität. Sie bestätigen nicht, dass ein Konto die Datensätze eines anderen Kontos nicht abfragen kann.
Autorisierungsfehler sind bei einer Demonstration des Happy Path besonders leicht zu übersehen. Der Entwickler sieht nach der Anmeldung das erwartete Profil und nimmt an, das System habe es geschützt. Ein Angreifer stellt eine andere Frage: Was geschieht, wenn die Anfrage keine Sitzung enthält oder eine Datensatzkennung ändert?
KI-Coding-Agenten interagieren auch programmatisch mit Infrastruktur. UpGuard wies darauf hin, dass Supabase RLS standardmäßig für Tabellen aktiviert, die über Teile seines Dashboards erstellt werden, während programmatisch erstellte Tabellen zusätzliche Sorgfalt erfordern.
Dieser Unterschied kann folgenreich werden, wenn ein Agent ein Datenbankschema über SQL oder eine API erstellt. Eine Schutzvorgabe, die an einen Erstellungsworkflow gebunden ist, deckt nicht automatisch jeden Zugang zur Plattform ab.
Supabase erkannte diese breitere Herausforderung der Nutzbarkeit in seinem Sicherheitsrückblick 2025 an. Das Unternehmen erklärte, RLS sei flexibel, könne aber für Entwickler, die mit diesem Muster neu sind, komplex sein.
Im Laufe des Jahres 2025 ergänzte Supabase sicherere Standardeinstellungen und baute seinen Security Advisor aus. Außerdem gab es Projekten mehr Kontrolle über die Data API, einschließlich der Option, sie zu deaktivieren oder statt des standardmäßigen public-Schemas ein benutzerdefiniertes Schema freizugeben.
Diese Änderungen helfen, beseitigen jedoch weder bestehende Projekte noch korrigieren sie jede generierte Migration. Sicherheitstools können häufige Fehler markieren, aber eine Richtlinie kann logisch weiterhin falsch sein, obwohl sie eine grundlegende Prüfung besteht.
Eine generierte Regel könnte die falsche Kennung vergleichen, einen Aktualisierungspfad übersehen oder Lesezugriffe schützen, während sie unautorisierte Schreibzugriffe erlaubt. Sie könnte bei einer Tabelle funktionieren, aber eine verbundene Tabelle öffentlich lassen.
Die menschliche Person, die den Agenten beaufsichtigt, muss erkennen, dass dieses fehlende Verhalten existiert. Ein Anfänger, der nichts über RLS, Rollenberechtigungen oder Mandantentrennung weiß, wird das Modell möglicherweise nie bitten, diese Aspekte zu testen.
Dadurch entsteht eine Asymmetrie zwischen Entwicklung und Prüfung. Eine Funktion zu erzeugen, erfordert einen Prompt. Nachzuweisen, dass diese Funktion jede Identität und jeden Vorgang sicher verarbeitet, setzt ein Bedrohungsmodell, Negativtests und eine sorgfältige Prüfung der erzeugten Artefakte voraus.
Frühere Studien deuten darauf hin, dass es sich um ein wiederkehrendes Muster und nicht um ein isoliertes Umfrageergebnis handelt. UpGuard verwies auf Untersuchungen zu Unternehmen aus dem Umfeld von Y Combinator, Anwendungen von KI-Entwicklungsplattformen und unabhängigen Websites.
Modern Pentest berichtete, dass 28 Prozent von 107 untersuchten Y-Combinator-Start-ups personenbezogene Daten über Supabase-Konfigurationen offenlegten. Eine weitere Studie prüfte 1.072 vibe-coded Apps und fand bei 39 davon Tabellen, die über einen öffentlichen Supabase-Schlüssel lesbar waren.
Die Stichproben und Methoden unterscheiden sich, daher sollten ihre Prozentwerte nicht zusammengeführt werden. Dennoch fand jede Untersuchung Varianten desselben Fehlers: für Clients sichtbare Verbindungsinformationen, kombiniert mit Datenbankberechtigungen, die weiter reichten als von der Anwendung vorgesehen.
Ein Vorfall im Februar 2026 machte die Folgen besonders sichtbar. Das Sicherheitsunternehmen Wiz stellte fest, dass Moltbook, ein als Plattform für KI-Agenten dargestelltes soziales Netzwerk, ein falsch konfiguriertes Supabase-Backend hatte.
Laut der Moltbook-Untersuchung erlaubte die Datenbank Lese- und Schreibzugriff auf Plattformdaten. Zu den offengelegten Daten gehörten 35.000 E-Mail-Adressen und 1,5 Millionen API-Authentifizierungstokens.
Wiz erklärte, das Problem bei einer nichtinvasiven Prüfung durch die Analyse clientseitigen JavaScripts gefunden zu haben. Das Moltbook-Team sicherte die Datenbank innerhalb weniger Stunden nach der Meldung.
Der Vorfall lieferte ein prägnantes Beispiel für den aktuellen Zielkonflikt. KI-Unterstützung half dabei, einen Dienst zu erstellen, der rasch Aufmerksamkeit gewann, doch der sichtbare Erfolg der Anwendung verdeckte einen kritischen Fehler bei der Datenbankzugriffskontrolle.
Für Organisationen, die KI-entwickelte Software bewerten, verändert dies die Bedeutung eines funktionierenden Prototyps. Eine Demonstration sagt heute weniger über Produktionsreife aus, weil KI sichtbare Abläufe abschließen kann, bevor jemand das darunterliegende Sicherheitsmodell validiert.
Eine interne Engineering-Wissensdatenbank kann Teams dabei helfen, Architekturentscheidungen und Prüfnachweise zu bewahren. Sie kann Datenbanktests nicht ersetzen, aber sie kann verhindern, dass Sicherheitsannahmen zwischen Prompts und Übergaben verlorengehen.
„Secure by Default“ trifft auf geteilte Verantwortung
Der zentrale Konflikt besteht zwischen sicheren Plattformstandards und einem Modell geteilter Verantwortung, das unerfahrenen Kunden weiterhin die Kontrolle über folgenschwere Einstellungen überlässt.
Supabase Chief Information Security Officer Bil Harmer sagte TechCrunch, das Unternehmen habe die Forschung von UpGuard vor seiner Stellungnahme nicht geprüft. Er erklärte, Supabase-Projekte seien standardmäßig sicher, und bezeichnete Sicherheit als geteilte Verantwortung.
Diese Position entspricht einem üblichen Cloud-Modell. Der Anbieter sichert seine gehostete Plattform und stellt Zugriffskontrollen bereit. Kunden entscheiden, welche Nutzer und Anwendungen auf ihre Daten zugreifen dürfen.
Die Unterscheidung ist berechtigt. UpGuard berichtete weder über eine Kompromittierung der Unternehmenssysteme von Supabase noch über die Umgehung einer korrekt konfigurierten RLS-Richtlinie. Die offengelegten Datenbanken gehörten Kunden, deren Einstellungen einen weitergehenden Zugriff erlaubten.
Standardeinstellungen können jedoch nicht nur bei der Projekterstellung bewertet werden. Sie umfassen auch die praktischen Wege, über die Menschen und Coding-Agenten Tabellen erstellen, APIs veröffentlichen, Beispiele kopieren und Anwendungen bereitstellen.
Ein System kann sicher starten und später durch eine von einem Agenten erzeugte Migration offengelegt werden. Es kann außerdem einen sicheren Dashboard-Workflow bieten, während ein programmatischer Workflow einen anderen Sicherheitszustand erzeugt.
Der Begriff „secure by default“ braucht daher eine klar definierte Grenze. Bedeutet er, dass ein neues Projekt nichts offenlegt? Deckt er jeden unterstützten Weg zur Tabellenerstellung ab? Warnt er Nutzer, bevor Produktionsdaten in eine Tabelle ohne RLS gelangen?
Geteilte Verantwortung setzt außerdem voraus, dass jede Partei ihre Aufgabe versteht. Erfahrene Cloud-Ingenieure wissen, dass eine öffentliche Client-Kennung mit serverseitiger Autorisierung kombiniert werden muss. Viele Vibe-Coder wissen das nicht.
Diese Wissenslücke macht die Plattform nicht allein für Kundenfehler verantwortlich. Sie erhöht jedoch den Druck auf Supabase und Anbieter von KI-Coding-Lösungen, unsichere Zustände schwerer erzeugbar und leichter erkennbar zu machen.
Die Plattform hat sich bereits in diese Richtung entwickelt. Der Security Advisor von Supabase prüft häufige Datenbankprobleme, während die Produktions-Checkliste Nutzer dazu auffordert, RLS für alle relevanten Tabellen zu aktivieren und Richtlinien zu überprüfen.
Ein strengeres Design könnte Produktionszugriff auf eine ungeschützte Tabelle blockieren oder eine ausdrückliche Ausnahme verlangen. Solche Maßnahmen würden unbeabsichtigte Offenlegungen reduzieren, könnten jedoch auch legitime öffentliche Datensätze und schnelle Entwicklung behindern.
Supabase muss diese Fälle abwägen, ohne jede öffentliche Tabelle als Schwachstelle zu behandeln. Eine Speisekarte, eine öffentliche Rangliste oder ein veröffentlichtes Verzeichnis können anonyme Lesezugriffe vernünftigerweise erlauben.
Die Plattform kann die Absicht nicht allein aus einem Tabellennamen ableiten. Eine users-Tabelle ist verdächtiger als eine products-Tabelle, doch eine Anwendung könnte Nutzerprofile absichtlich veröffentlichen und E-Mail-Adressen zugleich privat halten.
Automatisierte Tools stehen vor derselben Mehrdeutigkeit. Sie können erkennen, dass eine anonyme Rolle eine Tabelle lesen darf. Ob dieser Zugriff dem Produktversprechen widerspricht, lässt sich jedoch nur mit Geschäftskontext bestimmen.
Das ist der Kern des Zielkonflikts. Flexible Datenbankrichtlinien ermöglichen Entwicklern den Bau vieler Arten von Anwendungen, doch Flexibilität schafft Raum für stille Fehler. Meinungsstarke Einschränkungen verhindern Fehler, begrenzen aber legitime Designs.
KI-Assistenten fügen eine weitere verantwortliche Partei hinzu. Ein Entwickler kann Supabase wählen, weil ein Agent es empfohlen hat, und sich anschließend auf diesen Agenten verlassen, um Schema und Richtlinien zu erzeugen.
Der Modellanbieter hostet die Datenbank nicht, während Supabase nicht jeden erzeugten Befehl kontrolliert. Der Eigentümer der Anwendung bleibt den Nutzern gegenüber verantwortlich, selbst wenn er das resultierende Autorisierungsmodell nicht erklären kann.
Diese fragmentierte Kette macht Sicherheitsfehler schwerer zuzuordnen und leichter wiederholbar. Jeder Beteiligte kann auf Dokumentation oder die Konfiguration einer anderen Partei verweisen, während die betroffene Person nur sieht, dass private Informationen öffentlich wurden.
Für Unternehmenskäufer besteht die praktische Reaktion darin, das vollständige Entwicklungssystem zu bewerten. Anbieterzertifizierungen sind wichtig, ebenso aber Bereitstellungskontrollen, Code-Reviews, Datenbanktests, Protokollierung, Incident Response und die Erfahrung der Personen, die KI-Agenten beaufsichtigen.
Was die Zahlen zeigen – und was nicht
Die Studie zeigt eine große Angriffsfläche, doch ihre Methodik belegt weder 16.326 bestätigte Datenschutzverletzungen noch misst sie den gesamten Supabase-Kundenstamm.
UpGuard begann mit Domains, die auf eine Nutzung von Supabase hindeuteten, nicht mit einer Zufallsstichprobe aller Anwendungen auf der Plattform. Die Quellen bevorzugten Websites, die über Webtechnologie-Datensätze sichtbar waren.
Die Forschenden fragten anschließend nach einer Tabelle namens users. Diese Wahl war sinnvoll, weil viele Anwendungen Nutzerdaten verwalten, lenkte die Untersuchung jedoch auch in Richtung von Datenbanken, die wahrscheinlich personenbezogene Informationen enthalten.
UpGuard legte diese Einschränkung offen. Das Unternehmen erklärte, seine Ergebnisse seien teilweise auf PII ausgerichtet, weil es bewusst eine häufige, mit Personen verbundene Tabelle ausgewählt habe.
Die Gesamtzahl von 16.326 umfasst Datenbanken mit lesbaren Tabellen. Das bedeutet nicht, dass jede Tabelle vertrauliche Datensätze enthielt. Manche Projekte könnten Daten absichtlich veröffentlicht, synthetische Informationen verwendet oder nicht mehr gepflegt worden sein.
Eine Schemaanalyse misst potenzielle Offenlegung zudem anders als eine forensische Untersuchung auf Zeilenebene. Eine Spalte namens password ist ein ernstes Warnsignal, doch ihre bloße Existenz beweist nicht, dass sie aktive Zugangsdaten enthielt.
Die Forschenden validierten ausgewählte Fälle manuell und berichteten konkrete Datensatzanzahlen aus diesen Datenbanken. Diese Beispiele zeigen, dass zumindest einige Offenlegungen reale, sensible Daten in relevantem Umfang betrafen.
Die Forschung kann zudem nicht bestimmen, wie viele Außenstehende vor der Meldung auf die Datenbanken zugriffen. Öffentliche Verfügbarkeit schafft Risiken, ist aber kein Beweis dafür, dass kriminelle Akteure die Informationen entdeckten oder herunterluden.
Dieser Unterschied trennt eine Datenexponierung von einer bestätigten Datenpanne. Eine Exponierung bedeutet, dass unbefugter Zugriff möglich war. Eine Datenpanne erfordert im Allgemeinen Belege dafür, dass eine unbefugte Partei tatsächlich auf die Daten zugegriffen oder sie erlangt hat.
Organisationen sollten diese Unterscheidung nicht nutzen, um das Ereignis herunterzuspielen. Sobald sensible Datensätze ohne angemessene Autorisierung erreichbar sind, fehlen Ermittlern möglicherweise ausreichende Protokolle, um nachzuweisen, wer darauf zugegriffen hat.
Die Studie berechnet auch keine Exponierungsrate über alle Supabase-Projekte hinweg. UpGuard analysierte rund 300.000 Kandidaten-Domains, während eine Organisation mehrere Domains oder Projekte betreiben kann.
Inaktive Websites und falsche Technologieindikatoren können diesen Nenner zusätzlich erschweren. Die Endzahl ist am besten als entdeckte Population zu verstehen, nicht als Prozentsatz der Supabase-Kunden.
Auch mit diesen Vorbehalten stellen 16.326 lesbare Datenbanken eine erhebliche Angriffsfläche dar. Ein böswilliger Akteur könnte denselben allgemeinen Entdeckungsprozess automatisieren und Tabellen mit wertvollen Feldern priorisieren.
Die detaillierten Fälle schwächen zudem das Argument, es habe sich um harmlose Demo-Projekte gehandelt. Einwanderungsdaten, Standorte von Notunterkünften, private Kommunikation Erwachsener, Kennzeichen und Einmalpasscodes haben eindeutige Auswirkungen auf Privatsphäre und Sicherheit.
Auch die Reaktion von Supabase verdient dieselbe Präzision. Das Unternehmen erklärte, es benachrichtige betroffene Kunden, wenn es von Sicherheitsproblemen erfahre. Das bestätigt nicht, wie viele Projekte benachrichtigt wurden, wie schnell sie reagierten oder wie viele Exponierungen weiterhin offen waren.
UpGuard erklärte, in bedeutenden validierten Fällen die Eigentümer der Anwendungen benachrichtigt zu haben. Der öffentliche Bericht nannte keine vollständige Behebungsquote für alle 16.326 Datenbanken.
Diese Lücken sollten die Berichterstattung über die Ergebnisse prägen. Die Belege stützen die Einschätzung eines weitverbreiteten Konfigurationsproblems und mehrerer schwerwiegender Offenlegungen. Sie stützen jedoch nicht die Behauptung, dass Supabase selbst gehackt wurde oder dass jede identifizierte Datenbank sensible Datensätze preisgab.
Sie lassen zudem eine wichtige Vergleichsfrage offen. Vergleichbare gehostete Datenbanken könnten ähnliche Probleme aufweisen, wenn Forschende eine gleichwertige Methode im Internetmaßstab anwenden würden.
Firebase, Appwrite, selbstverwaltete PostgreSQL-Bereitstellungen und andere Backend-Dienste stellen unterschiedliche Schnittstellen bereit und verwenden unterschiedliche Berechtigungsmodelle. Entwickler können jede dieser Lösungen falsch konfigurieren.
Supabase zieht Aufmerksamkeit auf sich, weil seine clientfreundliche Architektur, automatischen APIs und Beliebtheit bei KI-Coding-Workflows das Problem sichtbar machen. Popularität erhöht sowohl die Zahl sicherer Bereitstellungen als auch die Zahl der Fehler.
Eine faire Bewertung sollte Supabase daher nicht als einzigartig unfähig darstellen, Daten zu schützen. Die stärkere Schlussfolgerung lautet, dass seine Verbreitung unter unerfahrenen Entwicklern die Benutzerfreundlichkeit von Zugriffskontrollen zu einem Anliegen auf Plattformebene macht.
Drei Signale werden zeigen, ob das Risiko sinkt
Die nächste Phase sollte anhand messbarer Produktänderungen, Belegen für Abhilfemaßnahmen und unabhängigen Nachtests beurteilt werden – nicht anhand allgemeiner Sicherheitsversprechen.
Das erste Signal ist, wie Supabase mit programmatisch erstellten Tabellen umgeht. Coding-Agenten arbeiten häufig über SQL, Verwaltungsschnittstellen und automatisierte Migrationen statt über manuelle Dashboard-Klicks.
Eine aussagekräftige Änderung würde RLS und restriktive Berechtigungen über alle Erstellungspfade hinweg konsistent machen oder eine ausdrückliche Entscheidung verlangen, bevor eine Tabelle über die Data API erreichbar wird. Klare Warnungen innerhalb von Agenten-Workflows würden diesen Schutz stärken.
Wenn Supabase die Lücke zwischen Dashboard- und programmatischer Erstellung schließt, würde dies die Ansicht stärken, dass sicherere Standardeinstellungen Sicherheitsrisiken durch Vibe Coding verringern können. Bleiben die Workflows unterschiedlich, werden unerfahrene Entwickler weiterhin in unsichere Zustände geraten, ohne sie zu erkennen.
Das zweite Signal sind Daten zur Behebung. Supabase und UpGuard können erläutern, wie viele identifizierte Projekte Benachrichtigungen erhielten, wie viele Eigentümer reagierten und wie viele Datenbanken keine unbeabsichtigten Datensätze mehr offenlegten.
Eine hohe Behebungsrate würde zeigen, dass Benachrichtigungen und Sicherheitswerkzeuge den bestehenden Rückstand reduzieren können. Eine niedrige Rate würde darauf hindeuten, dass viele Projekte aufgegeben, schlecht gewartet oder von Personen betrieben werden, die die Konfiguration nicht beheben können.
Betroffene Organisationen müssen außerdem feststellen, ob offengelegte Datensätze eine Benachrichtigung der Nutzer oder eine regulatorische Meldung erfordern. Diese Entscheidung hängt vom Standort, der Art der Daten, den Zugangsnachweisen und dem geltenden Recht ab.
Das dritte Signal sind unabhängige Nachtests in den kommenden Monaten. Forschende sollten vergleichbare Scans wiederholen und transparente Methoden veröffentlichen, die absichtlich öffentliche Daten von sensiblen Offenlegungen unterscheiden.
Eine sinkende Zahl von Datenbanken würde die Strategie von Supabase mit sichereren Standardeinstellungen stützen. Eine stabile oder steigende Zahl würde darauf hinweisen, dass Plattformwachstum und KI-gestützte Entwicklung unsichere Projekte schneller hervorbringen, als bestehende Kontrollen sie korrigieren können.
Auch Anbieter von KI-Coding verdienen während dieser Nachtests eine genauere Prüfung. Ihre Agenten sollten Richtlinien nach dem Prinzip minimaler Berechtigungen erstellen, negative Autorisierungstests generieren und warnen, wenn eine Bereitstellung personenbezogene Informationen offenlegt.
Entwickler müssen Supabase oder KI-Coding nicht aufgeben, um verantwortungsvoll zu reagieren. Sie müssen generierte Software als nicht vertrauenswürdig behandeln, bis ihr Autorisierungsverhalten getestet wurde.
Das bedeutet, anonymen und authentifizierten Zugriff getrennt zu prüfen, jede Datenbankoperation zu testen, Views zu überprüfen, Server-Schlüssel zu schützen und Schnittstellen zu deaktivieren, die die Anwendung nicht benötigt.
Teams sollten auch die Entscheidungen hinter diesen Kontrollen festhalten. Eine durchsuchbare KI-Wissensdatenbank kann Anforderungen, generierte Migrationen, Audit-Ergebnisse und Behebungsarbeiten verbinden, ohne Dokumentation zu einem nachträglichen Gedanken werden zu lassen.
Die Geschichte der Datenoffenlegung bei Supabase handelt letztlich von einer Verantwortlichkeitslücke. Plattformen bieten konfigurierbare Kontrollen, KI-Agenten setzen Anwendungen zusammen, und Nutzer vertrauen der fertigen Oberfläche.
Wer überprüft die unsichtbaren Berechtigungen, bevor echte Informationen in das System gelangen? Jede Organisation, die eine KI-generierte App ausliefert, sollte diese Frage mit Testergebnissen, benannten Verantwortlichen und Nachweisen verweigerten Zugriffs beantworten können.
