Die sichere Voreinstellung gilt dem Dashboard, nicht dem Prompt

Im Quelltext jeder Seite, die ein KI-Baukasten zusammensetzt, steht ein Schlüssel im Klartext. Das ist Absicht. Die Dokumentation von Supabase, der Datenbank hinter vielen dieser Seiten, führt ihn unter „Safe to expose online“¹ und zählt auf, wo er stehen darf, bis hin zum Quelltext. Zwei Zeilen tiefer hängt die Bedingung, unter der das gilt: „For full protection make sure: You have enabled Row Level Security on all tables.“ Ob diese Voreinstellung greift, entscheidet sich, lange bevor der Erbauer zum ersten Mal an Sicherheit denkt. Eva Wolfangel hat am 28. April in der ZEIT den Fall einer Gründerin beschrieben, deren Kundendatenbank offen im Netz stand: Namen, Adressen, teils Zahlungsdaten, Chats. Geraten wurde dafür kein Passwort, geknackt keine Software.

Zwei Schlösser entscheiden, ob die Datenbank einem Fremden antwortet#

Ein Fremder kopiert den Schlüssel aus dem Quelltext und stellt damit eine gewöhnliche Frage an die Datenbank. Zwischen dieser Frage und den Daten liegen zwei Schlösser. Das äußere ist eine Berechtigung: Wer eine Tabelle im Schema `public` anlegt, verteilt damit bisher automatisch Lese- und Schreibrechte an die Rollen `anon`, `authenticated` und `service_role`, alle vier Rechte namentlich in der Dokumentation aufgeführt². Das innere ist die Row-Level Security, die Regel, dass eine Anfrage nur die eigenen Zeilen sieht. Eine gewöhnliche PostgreSQL-Datenbank zeigt eine frische Tabelle niemandem außer ihrem Eigentümer; die automatisch verteilten Rechte sind der Punkt, an dem die Plattform davon abweicht.

Unsichere Voreinstellungen sind nichts Neues. Oracle-Datenbanken liefen jahrelang mit offenen Standardkonten, für offene Speicher-Eimer bei Amazon gibt es eigene Suchmaschinen. Neu ist, wer den Fehler macht und wie viele: eine wachsende Zahl von Menschen, die Software eher beschreiben, als sie zu schreiben.

Row-Level Security schaltet sich nur im Dashboard von selbst ein#

Das innere Schloss steht nicht pauschal offen. Die Dokumentation³ sagt, die Row-Level Security sei „enabled by default on tables created with the Table Editor in the dashboard“, und schiebt den Satz hinterher, an dem alles hängt: „if you create one in raw SQL or with the SQL editor, remember to enable RLS yourself“. Wer eine App aus einem Satz beschreiben lässt, öffnet den Table Editor nie; ihre Tabellen entstehen aus generiertem SQL. Auf diesem Weg richtet sich die Erinnerung an das innere Schloss an einen Menschen, der von dessen Existenz nichts weiß.

Wer Software beruflich baut, liest das mit einem Schmunzeln, und das Schmunzeln setzt voraus, dass der Bauende hätte wissen können, was er falsch macht. Der verbreitete Rat, man solle die KI selbst nach der Sicherheit fragen, führt in die andere Richtung: In einem kontrollierten Versuch⁴ mit 400 Codeproben über 40 Runden stiegen die kritischen Schwachstellen schon nach fünf Nachbesserungsrunden um 37,6 Prozent. Das ist ein Preprint und ein Laborwert, kein Feldbefund.

Die neue Voreinstellung greift am 30. Oktober und nur nach vorn#

Am äußeren Schloss bewegt sich etwas: Der automatische Zugriff auf neue Tabellen fällt weg. Das Änderungsprotokoll⁵ nennt zwei Stichtage: seit dem 30. Mai 2026 gilt das neue Verhalten für neue Projekte, am 30. Oktober 2026 wird es auf alle bestehenden durchgesetzt.

Dieselbe Seite schreibt zweimal hin, wie weit die Änderung reicht: „Existing tables are not affected in your project, they keep their current grants and stay reachable.“ Auch nach dem 30. Oktober schließt sich damit keine Tabelle, die heute offen steht.

Zwischen den beiden Terminen setzt der Anbieter selbst an die Stelle der Voreinstellung das, was gegenüber dieser Bevölkerung wenig ausrichtet: Dieselbe Seite kündigt an, der Security Advisor markiere die betroffenen Tabellen samt Reparatur-SQL, und die aktiven Projekte bekämen eine Mail. Ein Prüf-Panel erreicht den, der das Dashboard öffnet; eine geschlossene Voreinstellung erreicht auch den, der nie erfährt, dass er eine Datenbank betreibt. Der Weg dorthin verlangt vom Laien zudem mehr Konfigurationsarbeit als vorher: Künftig muss jede Tabelle jeder Rolle jede Berechtigung ausdrücklich zugewiesen bekommen.

Wer den Schaden trägt, hat das Werkzeug nie gewählt#

Die Gründerin, die sich ihre App zusammenbauen ließ, verliert im schlimmsten Fall ihre Website. Ihre Kundschaft verliert die Mailadresse, das wiederverwendete Passwort, den Lebenslauf, die Gesundheitsakte. Wer dort mit seinen Daten steht, hat den Prompt nie geschrieben und von der Firma dahinter oft nie gehört.

Wie viele es sind, ist nur der Größenordnung nach bekannt. Ein Sicherheitsforscher fand im März 2025⁶ 303 offene Endpunkte über 170 Projekte, rund 10,3 Prozent der geprüften Seiten. Sein Skript lief über die öffentlich gelisteten Startseiten, nicht über tiefere oder angemeldete Bereiche, und 170 ist deshalb eine Untergrenze; gemessen wird der Bestand von niemandem⁷. Die Kennung CVE-2025-48757⁸ traf am Ende den App-Baukasten obendrauf, nicht die Datenbankplattform, deren Rechtevergabe die Tür geöffnet hatte. Alle 170 sind bestehende Projekte.

Für Dinge, die mit zu wenig Wissen Dritte gefährden, kennt die Gesellschaft sonst den geregelten Bereich: Ein Tragwerk, eine Elektroinstallation, ein Fahrzeug brauchen eine Zulassung, beim Auto inzwischen samt Cyber-Regel mit Fixkosten⁹. Software, die Zahlungen abwickelt und Gesundheitsdaten hält, braucht keine. Der Cyber Resilience Act¹⁰ gibt dem ein Datum: in Kraft seit dem 10. Dezember 2024, Meldepflichten ab dem 11. September 2026, Hauptpflichten ab dem 11. Dezember 2027. Eine Zulassung schafft er nicht; er verpflichtet Hersteller zur Konformität über Planung, Entwurf, Entwicklung und Wartung.

Nach der ersten großen Aufarbeitung Ende 2025 supabase.com ↗ hieß es, die Supabase-Sache sei erledigt. Erkennung ist eine Höflichkeit gegenüber den Sorgfältigen, und selbst dort, wo Sorgfältige sie betreiben, blieb ein Angriff schon einmal drei Monate unbemerkt. Dass die Geschliffenheit der KI-Antwort das verschärft, weil aus flüssiger Sprache auf einen scharfen Verstand geschlossen wird, reicht über diese eine Plattform hinaus bis in die Statik einer ganzen Cybernation.

Am 30. Oktober 2026 wird sich für die 170 abgezählten Projekte von selbst nichts ändern. Prüfen lässt sich das am 31. Oktober mit derselben gewöhnlichen Abfrage: Antwortet die Datenbank weiter mit Daten, hat die Reparatur diese Projekte nicht erreicht. Widerlegt wäre die Vorhersage, wenn Supabase bereits erteilte Rechte einzieht, statt nur neue nicht mehr zu vergeben. Im Änderungsprotokoll steht bislang der gegenteilige Satz.

Anlass: Eva Wolfangels Reportage „Vibe-Coding: Gesundheitsdaten, Passwörter, Kundendaten …“, DIE ZEIT, 28. April 2026, hinter der Paywall; geprüft wurde der öffentliche Teaser, aus dem der Fall der Gründerin stammt. Belege aus eigener Recherche: der Wortlaut zum öffentlichen Schlüssel, zu den Berechtigungen und zur Row-Level Security sowie beide Stichtage aus Dokumentation und Änderungsprotokoll von supabase.com; 303 offene Endpunkte über 170 Projekte und die Methodengrenze des Startseiten-Scans bei mattpalmer.io; die Kennung CVE-2025-48757 bei nvd.nist.gov (am Prüftag nicht erreichbar; die Zuschreibung an den App-Baukasten steht in der verlinkten Erklärung des Forschers); die 37,6 Prozent aus einem Preprint (arxiv.org, 2506.11022); die Fristen des Cyber Resilience Act bei digital-strategy.ec.europa.eu. Abruf aller Onlinequellen: 12. August 2026.