SecurityRLSSupabaseIncident ReportAnalyse

Drei Tage bis zum Aus: was Moltbook über Row-Level-Security lehrt

Veröffentlicht am 7. April 2026 · 6 min Lesezeit · von Torben Schwellnus

Drei Tage bis zum Aus

Was Moltbook über Row-Level-Security lehrt — und warum ich diesen Fehler selbst schon gemacht habe

Im Februar 2026 ging Moltbook online — ein KI-getriebenes soziales Netzwerk, in dem Agenten miteinander interagieren und Nachrichten austauschen. Komplett vibe-gecodet, gestartet mit großem Marketing-Aufwand und einer kleinen, aber lautstarken Beta-Community.

Drei Tage später war es vorbei.

Ein Sicherheitsforscher hatte über die öffentliche API der App auf alle Datensätze zugegriffen: 1,5 Millionen Authentifizierungs-Tokens, 35.000 E-Mail-Adressen, private Nachrichten zwischen Nutzern. Jeder mit dem öffentlichen API-Schlüssel — der bei Supabase-Anwendungen fast immer im Frontend eingebettet und damit weltweit lesbar ist — konnte die komplette Datenbank lesen, schreiben und ändern.

Die Ursache war keine raffinierte Schwachstelle, kein Zero-Day, kein verschachtelter Auth-Bypass. Es war eine einzige, sehr einfache Konfigurationseinstellung, die nie aktiviert wurde: Row-Level-Security auf der Supabase-Datenbank.

Dieser Vorfall ist wichtig, weil er ein Muster offenlegt, das die Marketing-Sprache der Vibe-Coding-Plattformen sorgfältig ausspart: die Default-Konfiguration ihrer empfohlenen Backends ist nicht sicher. Sie ist einfach — was etwas anderes ist. Und der Übergang von "einfach genug zum Anfangen" zu "sicher genug für Produktion" ist niemandes Verantwortung außer deiner.

Wenn du etwas auf Supabase, Firebase oder einem ähnlichen Backend-as-a-Service baust, bist du strukturell der gleichen Falle ausgesetzt wie Moltbook. Hier ist, warum.

Wie Supabase wirklich funktioniert

Supabase ist eine wundervolle Plattform. Sie gibt dir eine PostgreSQL-Datenbank, eine REST-API, Auth, Storage und mehr — alles in wenigen Minuten konfiguriert. Wenn du auf Lovable, Replit oder Bolt baust und eine Datenbank brauchst, ist Supabase oft die erste und naheliegendste Wahl. Die Vibe-Coding-Plattformen schlagen sie standardmäßig vor.

Das Problem: Supabases Standard-Konfiguration vertraut dem Frontend. Jede Abfrage gegen die API wird über einen sogenannten "anon key" authentifiziert — einen Schlüssel, der explizit dafür gedacht ist, im Frontend eingebettet zu sein und damit von jedem im Browser eingesehen werden kann. Dieser Schlüssel hat in der Standard-Einstellung Schreib- und Lesezugriff auf alle Tables.

Damit das funktionieren kann, ohne dass deine ganze Datenbank öffentlich ist, musst du Row-Level-Security (RLS) explizit konfigurieren. RLS sind kleine Policies, die direkt in PostgreSQL leben und für jede Zeile entscheiden: darf der aktuelle Nutzer diese sehen, ändern, löschen?

Wenn RLS deaktiviert ist und du den anon key im Frontend einbettest, ist deine Datenbank im Internet öffentlich. Nicht "im schlimmsten Fall" oder "wenn ein Angreifer einen Bug findet" — sondern strukturell, by design, dokumentiert.

⚠️ Beware the tech: Wie RLS in Supabase wirklich funktioniert

Standard-Verhalten in Supabase: jede neue Tabelle hat RLS deaktiviert. Mit deaktiviertem RLS und einem im Frontend eingebetteten anon key kann jeder im Internet:

alle Datensätze in dieser Tabelle lesen (SELECT * FROM users)

eigene Datensätze einfügen (INSERT INTO users)

bestehende Datensätze ändern (UPDATE users SET ...)

alle Datensätze löschen (DELETE FROM users)

Aktivieren ist trivial: ein Toggle in der Supabase-UI oder ein einzelnes SQL-Statement. Aber nach dem Aktivieren muss du auch noch Policies schreiben — sonst sperrst du dich selbst aus. Eine korrekte Policy für "Nutzer dürfen nur ihre eigenen Daten lesen" sieht so aus:
CREATE POLICY "users_own_data"
ON users FOR SELECT
USING (auth.uid() = user_id);
Das klingt simpel — und ist es auch, wenn du SQL kennst und PostgreSQL-Auth-Konzepte verstehst. Wenn du aber gerade vibe-codest, bist du an einem ganz anderen Punkt deines Workflows: du baust ein Feature, willst es testen, willst, dass die Daten durchfließen. RLS ist die Reibung, die zwischen "Idee" und "es funktioniert" steht.

Ich habe das selbst getan

Ich kenne diesen Punkt aus eigener Erfahrung. Vor einigen Monaten habe ich auf Lovable einen Prototypen gebaut. Supabase hatte ich angeschlossen — der naheliegende Weg, weil Lovable es genau so vorschlägt. Aber bei jedem Versuch, die Row-Level-Security korrekt einzurichten, lief etwas anders als erwartet. Die Policies wurden nicht durchgesetzt, die Login-Session war plötzlich leer, oder eine Abfrage, die im SQL-Editor funktionierte, lieferte über die API plötzlich keine Zeilen zurück.

Nach einem Nachmittag, an dem ich nicht weitergekommen bin, habe ich RLS komplett deaktiviert. Nur kurz, dachte ich, nur um voranzukommen.

Mein Prototyp ist nie öffentlich gegangen — das war von Anfang an die Verabredung mit mir selbst. Es lag nichts Sensibles drin, nichts, was DSGVO-relevant gewesen wäre, und niemand außer mir hatte die URL. Aber genau in diesem Moment habe ich verstanden, warum Moltbook und so viele andere Apps mit deaktiviertem RLS in Produktion landen.

Die Reibung ist echt. Die Frustration ist echt. Und der Schritt von "kurz mal deaktivieren, um voranzukommen" zu "ich vergesse, es wieder einzuschalten, weil mir niemand sagt, dass es noch aus ist" ist sehr klein. Wenn du es zwei Wochen später irgendwann in Produktion deployst, fragt dich keine Plattform: "Übrigens, RLS ist auf vier Tables deaktiviert — willst du das wirklich so live nehmen?"

Das ist kein Entwicklerfehler. Es ist ein Plattform-Fehler. Das System lässt einen Zustand zu, in dem die einzige verbleibende Schutzschicht zwischen deinen Nutzerdaten und dem öffentlichen Internet eine Konfigurationsoption ist, die du in einem hektischen Moment deaktiviert und nie wieder bewusst geprüft hast.

Warum das Muster überall ist

Wenn du nach "Supabase RLS not working" googelst, findest du tausende Stack-Overflow-Posts, Reddit-Threads und Discord-Diskussionen. Das gleiche Muster: Jemand will RLS aktivieren, eine Policy schreiben, eine Abfrage testen — und es funktioniert nicht wie erwartet. Daten kommen nicht durch. Login bricht. Build schlägt fehl.

Die Standard-Antworten in den Diskussionen: "Du musst dafür dieses und jenes konfigurieren." "Hast du den Service-Role-Key statt des Anon-Key benutzt?" "Hast du auth.uid() in deiner Policy?" "Cache eine Stunde lang invalidieren und dann erneut testen." Für jeden Schritt, den du verstehen musst, bevor RLS funktioniert, gibt es Vibe-Coder, die abbrechen und stattdessen RLS deaktivieren — explizit oder durch Workarounds wie USING (true)-Policies, die exakt nichts schützen.

Die Plattformen verschärfen das Problem. Lovable und Replit erwähnen RLS in ihrer KI-generierten Anleitung manchmal, aber nicht durchgängig. Sie testen nicht, ob es aktiviert ist. Sie warnen nicht, wenn deine App live geht und RLS noch deaktiviert ist. Sie unterscheiden nicht zwischen Prototyp und Produktion.

Damit bleibt das Risiko vollständig beim Builder hängen — also bei der Person, die am wenigsten Erfahrung mit Datenbank-Sicherheit hat, weil sie ja gerade auf eine Plattform setzt, die ihr genau diese Erfahrung ersparen sollte. Es ist eine Verantwortungs-Verteilung, die nicht funktioniert.

Die Zahlen bestätigen das. Eine Q1-2026-Untersuchung von über 200 vibe-gecodeten Anwendungen hat gezeigt, dass mehr als 60 % davon API-Schlüssel oder Datenbank-Credentials in öffentlichen Repositories oder Frontend-Bundles offenlegen. Eine breit angelegte Scan-Analyse von 5.600 öffentlich erreichbaren vibe-gecodeten Apps fand 2.000 hochkritische Schwachstellen, 400 offengelegte Secrets und 175 Fälle von exponierten personenbezogenen Daten — inklusive Gesundheitsdaten und Zahlungsinformationen.

Das ist kein Anti-Pattern. Das ist das Standard-Verhalten.

Was Moltbook gerettet hätte

Nicht ein Audit nach dem Vorfall. Auch nicht ein Audit eine Woche vor dem Launch — denn da war RLS in der Architektur schon nicht aktiv, und niemand hat es bemerkt.

Was Moltbook gerettet hätte, ist eine Routine: ein automatischer Pre-Launch-Check, der genau einen einzigen Punkt prüft — "sind alle Tables in der angeschlossenen Supabase-Instanz mit aktivem RLS und mindestens einer sinnvollen Policy konfiguriert?" Eine Checkliste, die für jede vibe-gecodete App vor dem Go-Live durchläuft. Drei Minuten Arbeit, ein klarer rot/grün-Bericht.

Genau das machen wir bei Lastable. Unser Full Technical Health Check prüft RLS-Status, Storage-Bucket-Sicherheit, exponierte Schlüssel im Frontend, fehlende Auth-Konfiguration auf Standard-Endpunkten.

Wenn du gerade eine Lovable-, Replit- oder Bolt-App in Produktion stellst und nicht hundertprozentig sicher bist, ob RLS oder vergleichbare Mechanismen aktiv sind, dauert der Quickscan auf lastable.dev genau 30 Sekunden für eine erste Einschätzung. Der einzige Preis: vielleicht musst du danach drei Stunden investieren, um zu reparieren, was du gefunden hast.

Aber das ist günstiger als drei Tage.

Quickscan starten →