16.326 Supabase-Datenbanken offen lesbar: Was der Befund für KI-gebaute Apps bedeutet

Stand: 27. September 2026. Anlass ist die Untersuchung vom 25. September.

Die Sicherheitsfirma UpGuard untersuchte rund 300.000 Domains mit Hinweisen auf Supabase und identifizierte 16.326 Datenbanken mit öffentlich lesbaren Tabellen. Zur Einordnung der möglichen Inhalte analysierten die Forscher überwiegend die Tabellenstrukturen, nicht sämtliche gespeicherten Datensätze. Mehr als die Hälfte enthielt Hinweise auf personenbezogene Informationen; ausgewählte Einzelfälle wurden zusätzlich geprüft. [1]

Diese Unterscheidung begrenzt die Aussagekraft der Zahl. Öffentlich lesbare Tabellen sind nicht automatisch 16.326 bestätigte Lecks persönlicher Daten. Ebenso wenig liefert die Untersuchung eine Zählung aller betroffenen Personen. Der Bericht beschreibt ein verbreitetes Konfigurationsproblem, keine nachgewiesene Übernahme der gesamten Supabase-Plattform.

Supabase stellt unter anderem gehostete Postgres-Datenbanken bereit, also den Datenspeicher hinter vielen Websites und Apps. UpGuard ordnet die Untersuchung in den Boom des sogenannten Vibe Coding ein: Entwickler lassen Anwendungen weitgehend durch KI-Assistenten erstellen. Wie viele der gefundenen Fehlkonfigurationen tatsächlich von KI verursacht wurden, weist die Studie jedoch nicht für jeden Fall nach. [1]

Die redaktionelle Konsequenz ist deshalb enger als ein pauschales Urteil über KI-Programmierung. Wenn eine Anwendung funktioniert, ist zunächst nur gezeigt, dass der vorgesehene Ablauf klappt. Ob fremde Besucher dieselben Daten ebenfalls abrufen können, ist eine andere Frage. Eine gelungene Anmeldung und ein hübsches Kundenportal beantworten sie nicht.

Ein zentraler Schutzmechanismus heißt Row Level Security, kurz RLS. Damit entscheidet die Datenbank für einzelne Datensätze, wer sie lesen oder verändern darf. Supabase erklärt das anhand nutzerbezogener Regeln: Eine Abfrage kann beispielsweise auf die Einträge des angemeldeten Nutzers begrenzt werden. Die Einschränkung wird bei der Datenbankabfrage durchgesetzt. [2]

Dazu kommen grundlegende Rechte für Tabellen. Sie bestimmen, ob eine Rolle überhaupt lesen, schreiben oder löschen darf. RLS-Regeln grenzen anschließend die betroffenen Zeilen ein. Beide Ebenen müssen zur Anwendung passen. Eine Regel, die allen nicht angemeldeten Besuchern sämtliche Zeilen zugänglich macht, schützt keine privaten Inhalte, auch wenn RLS formal eingeschaltet ist. [2]

Das lässt sich an einem gewöhnlichen Kundenportal erklären: Ein Kunde soll seine eigenen Einträge sehen. Es reicht nicht, fremde Einträge in der Oberfläche auszublenden. Auch eine direkte Datenanfrage muss an der Berechtigungsgrenze scheitern. Entscheidend ist die Kontrolle dort, wo die Daten ausgegeben werden.

Supabase unterscheidet ausdrücklich zwischen veröffentlichbaren und geheimen API-Schlüsseln. Ein veröffentlichbarer Schlüssel darf in einer Website oder ausgelieferten App vorkommen. Er identifiziert die Anwendung und ist kein Ersatz für die Anmeldung des einzelnen Nutzers. Den Zugriff auf Daten müssen die dazugehörigen Berechtigungen begrenzen. [3]

Geheime Schlüssel besitzen dagegen erhöhte Rechte und umgehen RLS. Sie gehören ausschließlich in kontrollierte Backend-Komponenten, etwa einen Server. Taucht ein solcher Schlüssel im ausgelieferten Programmcode auf, kann die Datenbank trotz vorhandener RLS-Regeln gefährdet sein. Ein öffentlich sichtbarer Schlüssel lässt sich deshalb nur beurteilen, wenn klar ist, um welchen Schlüsseltyp es sich handelt. [3]

Für die Abnahme einer KI-gebauten App ergibt sich daraus eine konkrete Frage: Welche Zugangsdaten gelangen auf das Gerät des Nutzers, und welche Rechte haben sie? Die Antwort muss sich aus der tatsächlichen Konfiguration ergeben.

Supabase beschreibt den Betrieb als geteilte Verantwortung. Der Anbieter übernimmt Infrastrukturaufgaben; Kunden bleiben unter anderem für Daten, Zugriffsverwaltung und die Anwendung von Schutzmaßnahmen zuständig. Auch Hinweise des Security Advisor, der typische Sicherheitsprobleme meldet, müssen sie bearbeiten. [4]

Die Dokumentation empfiehlt zudem Tests, die erlaubte und verbotene Datenzugriffe überprüfen. Dazu gehören verschiedene Nutzerrollen und Operationen wie Lesen, Ändern und Löschen. [2] Ein Test ausschließlich mit einem Administratorkonto zeigt gerade nicht, wie sich die Anwendung gegenüber einem fremden Besucher verhält.

Eine gesonderte Zahl für Deutschland lässt sich aus den hier ausgewerteten Angaben nicht belastbar ableiten. Der weltweite Befund ist trotzdem auch für hiesige App-Betreiber relevant. Die entscheidende Abnahmefrage lautet, ob die eingerichteten Zugriffsgrenzen nachweislich halten. Sie gehört vor die Übergabe einer Anwendung, unabhängig davon, wer oder welches Modell den Code geschrieben hat.