Mühle in 3D: Was hinter dem Supabase-Befund steht

Die Artikel Supabase-Sicherheit, Vibe Coding und die Cybernation und Vibe Coding vs. Agentic Engineering ist mehr als ein Buzzword-Streit erweitern den folgenden Text.

Zuerst berichtete DIE ZEIT zeit.de ↗ über eine Recherche, an der ich mehrere Wochen mitgearbeitet habe. Die Kurzfassung: Hunderte deutschsprachige Webseiten, viele davon offenkundig mit KI-Hilfe gebaut, geben sensible Daten ungeschützt ins Netz.

Gemeinsam ist ihnen ein Backend-as-a-Service, Supabase, und ein Konfigurationsmuster, das die Plattform per Default zulässt.

Dies hier ist kein zweiter Artikel. Es ist die längere technische Lesart dahinter, plus eine ordnungspolitische Note, die in der Reportage notwendig kürzer kommen muss.

Update 7. Mail 2026: WIRED¹ stützt sich am 7. Mail auf eine vergleichbare Analyse, die die Zahlen der zugänglichen personenbezogenen Daten bestätigt. Die Konfrontation der betroffenen Unternehmen ergibt, dass die Forscher ihre Erkenntnisse nicht ausreichend offengelegt und ihnen nicht genügend Zeit für eine Stellungnahme eingeräumt hätten. Diesen oft fehlenden Zusatzaufwand, kooperativ zwischen JournalistInnen, Herstellern, Sicherheitsorganisationen, Verantwortlichen und betroffenen Nutzern zu berichten, beschreibt der Text „Supabase-Sicherheit, Vibe Coding und die Cybernation“.

Mühle in 3D: Die einzelnen Züge sind einfach, aber das Spiel ist taktisch tiefer, als es auf den ersten Blick wirkt.#

Die einzelnen Züge beim Spiel Mühle sind einfach. Bei perfektem Spiel beider Seiten endet jede Partie unentschieden. Spieler und Gegenspieler verhalten sich jedoch selten perfekt. Das Absichern von Sicherheitslücken verhält sich ähnlich.

Eine einfache Sicherheitslücke hat eine Stelle. Man findet sie, man patcht sie, man ist fertig. Hier ist das anders. Oft gibt es viele Wege, die Angreifer kombinieren können, um an Informationen zu gelangen. Sei es über die REST-Schnittstelle, über GraphQL, über Realtime-Channels, über Storage-Pfade und über Edge-Funktionen. Schließt der Operator eine Tür, bleibt die nächste offen. Korrigiert er die Berechtigung auf der Tabelle, bleibt eine View daneben, die sie umgeht. Setzt er eine RLS-Policy, gilt sie für die Zeilen, nicht für das Schema, das die GraphQL-Introspektion weiterhin liefert. Sicherheit ist hier nicht ein Schalter, sondern ein Raster aus mindestens fünf Achsen, die sich gegenseitig nicht abdecken.

Diese Spielzüge sind nicht neu.

REST gibt es seit Jahren, GraphQL auch, Realtime und Storage ebenfalls. Vor Supabase arbeitete der heutige Supabase-CEO bereits 2019 an einer Software mit dem Namen Nimbus. Dort lernte er die Open-Source-Software PostgREST² kennen. Bis heute ist PostgREST ein zentraler Bestandteil von Supabase: Code search results³.

Auch der einzelne Zug, also einer Tabelle die Berechtigung zu entziehen oder eine RLS-Policy hinzuschreiben, ist nicht schwer. Was sich geändert hat, ist, was es kostet, den Mühlestein einmal sauber durch alle Dimensionen zu ziehen. Früher war das Wochenarbeit für ein einzelnes Projekt. Genau deshalb haben es kaum Operatoren bis zum Ende gemacht. Die Lücke war nicht versteckt, sie war nur teuer zu finden.

Diese Kosten sind auf zwei Seiten gleichzeitig zusammengefallen. Auf der Bauseite, weil Coding-Agenten Anwendungen in einer Geschwindigkeit produzieren, in der niemand mehr jede Achse händisch reviewt. Auf der Prüfseite, weil dieselbe Sorte Werkzeug eine Datenbank heute über alle fünf Achsen einmal durchgehen kann, in einer Zeit, die sich auf Stunden reduziert. Diese Recherche ist genau aus dieser kollabierenden Asymmetrie entstanden: Bauen ist billig geworden, glaubt man. Schwachstellen zu finden, ebenfalls. Wer beides nicht parallel macht, fällt auseinander.

Anthropic hat in dieser Woche sein neues Modell „Claude Mythos Preview“ unter Verschluss genommen, mit der Begründung, es sei zu gefährlich, weil es Sicherheitslücken besser finden könne als jeder Mensch. Die Erzählung ist: Gefahr beginnt mit dem nächsten, noch nicht ausgelieferten Modell. Der IT-Sicherheitsforscher Christoph Endres formuliert in der ZEIT die naheliegende Gegenthese, „das hätte man mit jedem anderen Modell auch machen können“, und beschreibt das Mythos-Marketing als Doomsday-Variante einer ohnehin laufenden Entwicklung.

Diese Recherche ist eine konkrete Illustration zu dieser Gegenthese. Sie ist mit dem aktuellen, breit verfügbaren Modell entstanden, einem Standardlauf, kein Spezialwerkzeug. Mein dokumentierter Praxistest mit Claude Opus 4.6 beschreibt einen autonomen Neun-Stunden-Lauf mit 711 Arbeitsergebnissen für unter zweihundert Euro. Das ist nicht zukünftige Kapazität, das ist heute. Was diese Recherche an Schwachstellen beschrieben hat, hätte vor einem Jahr Mannmonate gekostet. Heute geht es mit überschaubarem Werkzeug. Das gilt für die Hand, die baut, ebenso wie für die Hand, die prüft. Die ehrliche Konsequenz daraus ist eher, mehr unabhängiger Forschung Zugang zu solchen Modellen zu geben, nicht weniger.

Was Supabase in den letzten Wochen getan hat#

Supabase hat reagiert. Mehrfach, sichtbar, im offenen Code. Ein paar konkrete Punkte aus den letzten Wochen, in der Reihenfolge des Erscheinens:

• Im Table-Editor des Studios ist Row Level Security beim Anlegen einer neuen Tabelle per Default aktiviert. Auch der SQL-Editor warnt inzwischen: führt man dort ein CREATE TABLE ohne RLS aus, schiebt sich ein Modal davor, erklärt, dass anon und authenticated sonst lesen und schreiben können, und bietet einen „Run and enable RLS“-Button als sicheren Default. Beides bleibt eine Schicht, die im Studio greift, aber Coding-Agenten, die CREATE TABLE über Migrationen, die CLI oder die Datenbank-API direkt absetzen, sehen das Modal nicht. Genau dort soll ein „secure by default“-Modus ansetzen, der diese Woche aktiv wählbar ist und Ende Mai zum Standard werden soll.
• Im Detection-Tool Splinter eine Lint-Serie für die GraphQL-Schicht: erst eine Regel für an anon exponierte Tabellen, dann auf direktes Feedback hin in den Tagen danach erweitert um die Pendants für authenticated und für Funktionen, plus eine separate Regel für öffentlich gelistete Storage-Buckets.
• Im Studio seit heute der „RLS Tester“ als Preview-Feature: man kann eine Abfrage in der Rolle eines nicht eingeloggten oder eines eingeloggten Nutzers laufen lassen und sehen, welche RLS-Policy greift. Genau das Werkzeug, das im täglichen Gebrauch oft fehlt, um zu verstehen, ob eine Policy das tut, was man glaubt.
• Eine neue Default-Policy für die Schlüsselverwaltung (publishable und secret keys statt einer einzigen, langlebigen anon-JWT) ist ab dieser Woche aktiv wählbar und soll Ende Mai zum Standard werden.
• Realtime hat Authorization-Hooks bekommen, Storage hat strengere Pfad-Auflösungen, in Edge-Functions fließen Sicherheitskorrekturen aus einem internen Vorfall ein.

Das ist ernsthaft, und es ist mehr, als Plattformen in vergleichbarer Lage typischerweise innerhalb weniger Wochen liefern.

Was offen bleibt, und warum das nicht trivial ist#

Neue Projekte profitieren von den geänderten Defaults. Bestehende, gehostete Projekte tun das nicht. Das ist keine Boshaftigkeit der Plattform, das ist die ehrliche Schwierigkeit eines Default-Wechsels. Würde Supabase rückwirkend die Berechtigungen auf Millionen Projekten umkonfigurieren, würden tausende Anwendungen schlagartig nicht mehr funktionieren, weil sie genau auf den unsicheren Default gebaut sind. Die Plattform hat das nachvollziehbar entschieden.

Wer heute eine produktive Supabase-Datenbank betreibt, deren Projekt vor diesem Frühjahr angelegt wurde, ist nicht automatisch sicherer geworden. Die Verantwortung, die Lints zu prüfen, RLS auf jeder Tabelle zu aktivieren, GraphQL-Grants zu schließen, Realtime-Channels zu autorisieren, Edge-Functions auf JWT-Verifikation zu prüfen, liegt beim Operator. Sie liegt jetzt nur, anders als zuvor, mit Werkzeugen unterstützt da. Die Werkzeuge ersetzen die Prüfung nicht.

Jede Operatorin, jeder Operator eines bestehenden Supabase-Projekts sollte diese Woche einmal das Studio öffnen, die neuen Splinter-Lints durchlaufen lassen, die GraphQL-Berechtigungen für anon und authenticated reviewen und prüfen, ob die eingesetzten Schlüssel rotiert werden müssen. Das sind, je nach Projektgröße, zwei Stunden Arbeit, oder ein Tag.

Bedrohungslage hat sich verschoben, Datenschutz und Sicherheit müssen näher zusammen#

Der Zeitpunkt der Recherche ist kein Zufall. Wenn Menschen in einem KI-Chat einen Webshop bauen lassen, fällt die Schicht weg, die in klassischer Softwareentwicklung viele Defaults stillschweigend abgefangen hat. Eine Entwicklerin, die manuell ein Modell und eine Migration schreibt, sieht die Berechtigung. Ein Agent, der den gleichen Code in einer Session generiert, übernimmt den Default und gibt ihn an die Endnutzerin durch, die nie eine Datenbank angefasst hat. Damit wird die Default-Konfiguration einer Plattform aus einer Bequemlichkeitsfrage zu einer datenschutzrelevanten Vorentscheidung für das offene Internet.

Das ist eine Verschiebung, auf die unsere Aufsichtsstruktur nur teilweise eingerichtet ist. Datenschutzbehörden adressieren Verantwortliche im Sinne der DSGVO, also den Betreiber der Webseite. Cybersicherheitsbehörden adressieren Plattformen und Betreiber kritischer Infrastruktur. Ein US-amerikanischer Backend-Anbieter, dessen Default-Konfigurationen tausenden deutschen Unternehmen die Daten ihrer Kundinnen offenlegen, fällt ungemütlich zwischen beide Stühle. Genau hier liegt der Punkt, an dem Deutschland und Europa führen könnten.

Das setzt drei Dinge voraus, die heute nur unvollständig vorhanden sind. Erstens: bessere Abstimmung zwischen Datenschutz und Sicherheit. Eine offene Default-Konfiguration ist beides, eine technische Schwachstelle und ein potenzieller DSGVO‑Verstoß. Heute landet ein solcher Befund entweder beim BSI, das CVE-Vergabe und Koordinierung macht, oder bei einer Landesdatenschutzbehörde, die Einzelfälle prüft. Die strukturelle Frage, ob ein Plattform-Default so überhaupt zumutbar ist, fällt zwischen die beiden Mandate.

Zweitens: Kapazitäten. Wir haben bei dieser Recherche im Verhältnis zur Sache mit sehr wenig Personalstunden sehr viel gefunden. Was bedeutet, dass die Lücke nicht versteckt war. Sie war nur unbeobachtet. Eine staatliche Stelle, die kontinuierlich beobachtet, fehlt in der Breite. Mehr Kapazität an Stellen, die Plattform-Defaults systematisch gegen die deutsche Anwenderlandschaft prüfen, wäre der unaufgeregteste Hebel mit der größten Wirkung.

Drittens: ein Verständnis, dass Bedrohungslage nicht nur neue Angriffe meint, sondern auch geänderte Nutzungsmuster derselben Software. Supabase ist nicht in den letzten Monaten unsicherer geworden. Die Software, die einen entwicklungserfahrenen Operator voraussetzt, läuft heute massenhaft auf Projekten, die genau diesen Operator nicht mehr haben. Das ist eine eigene Klasse von Bedrohungslage, und sie wird, wenn der KI-Trend anhält, nicht abnehmen.

Was können Betroffene tun?#

• Studio öffnen, Advisor-Tab, die neuen Lints zur GraphQL-Schicht und zu öffentlich gelisteten Storage-Buckets prüfen.
• Wenn der RLS Tester für das Projekt verfügbar ist, jede sensible Tabelle gegen die Rollen anon und authenticated testen.
• Auf jeder Tabelle in public prüfen, ob RLS aktiviert ist und mindestens eine restriktive Policy existiert.
• Die Berechtigungen für anon und authenticated auf Tabellen und Funktionen reviewen, nicht nur die Zeilen.
• Storage-Buckets daraufhin prüfen, ob sie public=true sind und ob ID-Dokumente von uneindeutigen Asset-Buckets getrennt sind.
• Edge-Functions auf verify_jwt = true prüfen.
• Wenn das Projekt vor 2025 angelegt wurde, die Schlüsselrotation auf das neue publishable/secret-Modell einplanen.

Die Plattform liefert die Werkzeuge dafür inzwischen. Niemand sonst wird sie für dich anwenden.

Einen ersten Check kann man mit meinem Tool „Supabase Security Check – Ist Ihre Datenbank öffentlich?“ durchführen.

Dank an Eva Wolfangel für die Geduld, dieses Material in eine Geschichte zu übersetzen, die ohne Vorwissen lesbar ist, und an die Personen bei Supabase, die in den vergangenen Wochen sichtbar Code geschrieben haben statt Pressemitteilungen.

Presseberichterstattung#

Primärquelle#

ZEIT Online, 28.04.2026, 18:02 Uhr CEST „Vibe-Coding: Gesundheitsdaten, Passwörter, Kundendaten – alles liegt offen rum“ Von Eva Wolfangel zeit.de/digital/datenschutz/2026-04/vibe-coding-websites-ki-datenschutz-supabase zeit.de ↗

Pickups, deutschsprachig#

5min.at (Österreich), 28.04.2026 „KI-Webseiten: Hunderte Seiten lassen sensible Infos offen liegen“ 5min.at/5202604290350/ki-webseiten-hunderte-seiten-lassen-sensible-infos-offen-liegen⁴

IT-Boltwise, 29.04.2026 „Offene Datenbanken im Netz: Sicherheitsrisiken durch KI-Agenten“ it-boltwise.de/offene-datenbanken-im-netz-sicherheitsrisiken-durch-ki-agenten.html it-boltwise.de ↗

ComputerBase, 29.04.2026 „Hunderte Datenbanken offen im Netz: KI-Agenten übernehmen unsichere Voreinstellungen ohne Kontrolle“ computerbase.de/news/apps/hunderte-datenbanken-offen-im-netz-ki-agenten-uebernehmen-unsichere-voreinstellungen-ohne-kontrolle.97115⁵

t3n, 29.04.2026 „Sicherheitslücken durch Vibe-Coding: Sensible Website-Daten sind oft leicht auffindbar“ t3n.de/news/sicherheitsluecken-durch-vibe-coding-sensible-website-daten-sind-oft-leicht-auffindbar-1740385⁶

Meinungen#

Viele lesenswerte Kommentare unter dem Artikel: Vibe-Coding: Gesundheitsdaten, Passwörter, Kundendaten – alles liegt offen rum | DIE ZEIT zeit.de ↗

Screenshots aus der Software#

Tabellen mit RLS aktivieren.

Security Advisor aktiv nutzen.