RLS an heißt nicht abgesichert

Im Supabase-Dashboard steht bei deiner Tabelle ein grünes “RLS enabled”. Die Zugriffsregeln sind an. Das Gefühl danach: erledigt, abgehakt, weiter.

Es ist nicht erledigt. Das Häkchen sagt, dass ein Schloss an der Tür hängt. Ob es zugesperrt ist, sagt es nicht.

Wie die Tür aufgeht, ohne dass jemand es merkt

Der Ablauf war in vielen Projekten derselbe, und er ist völlig logisch.

Supabase warnt dich, dass eine Tabelle ohne Zugriffsregeln öffentlich lesbar ist. Du gibst die Warnung an den Agenten weiter. Der schaltet die Regeln ein. Danach funktioniert deine App nicht mehr, weil ohne eine konkrete Regel nichts mehr durchkommt. Du meldest den Fehler. Der Agent schreibt eine Regel, die das Problem löst.

Die schnellste Regel, die jedes Problem löst, ist die, die alles erlaubt: “Jeder darf jede Zeile lesen.”

Die App läuft wieder. Die Warnung ist weg. Das Häkchen ist grün. Und deine Daten liegen offen, wie vorher, nur mit einem grünen Häkchen davor.

Aktuelle Agenten wie Claude Code prüfen die Regeln öfter von sich aus und schreiben seltener so eine Alles-erlaubt-Regel. Sie können auch zwei Testnutzer anlegen und selbst nachsehen, ob einer die Daten des anderen liest. Passieren kann es trotzdem, vor allem bei einem Auftrag wie “mach die Fehlermeldung weg”. Dann ist die Meldung weg, und mehr war nicht gefragt.

Warum “der Schlüssel ist doch geheim” nicht hilft

Der öffentliche Schlüssel in deiner App ist mit Absicht öffentlich. Jeder Besucher kann ihn auslesen, das ist kein Fehler. Supabase sagt das selbst so: Der Schlüssel identifiziert dein Projekt, er schützt es nicht.

Was schützt, sind die Zugriffsregeln. Sonst nichts.

Der Test: ein zweiter Nutzer

Das ist der eigentliche Handgriff. Von Hand dauert er drei Minuten.

1. Lege einen zweiten Account in deiner App an. Nicht deinen Admin-Account, sondern einen frischen, der nichts besitzt.
2. Melde dich damit an.
3. Lass dir alle Daten einer Tabelle anzeigen, ohne Filter.
4. Prüfe, ob du dort nur deine eigenen Einträge siehst.

Siehst du Einträge anderer Nutzer, ist die Tabelle offen. Siehst du nur deine eigenen, greifen die Regeln.

Den Test kann auch der Agent für dich laufen lassen. Lass dir die Ausgabe zeigen, bevor du Nutzer einlädst, und prüf, dass er mit einer normalen Nutzer-Session gelaufen ist und nicht mit dem Admin-Zugang. Das ist dein Abnahmekriterium.

Warum Lesen allein nicht reicht

Eine Regel, die absichert, und eine, die alles durchlässt, sehen beide aus wie eine Regel. Beide stehen im Dashboard, beide machen die Warnung weg. Der Unterschied steckt in einem Ausdruck, den man beim Drüberschauen für eine Formalität hält.

Ein Agent hat getan, worum du gebeten hast, wenn die Fehlermeldung weg ist. Ob dabei die Tür offen blieb, zeigt erst ein Test. Deshalb zählt Ausführen mehr als Lesen.

Zwei Stellen, an denen der Test danebengeht

Getestet wird mit dem falschen Zugang. Der Admin-Zugang umgeht alle Regeln, das ist seine Aufgabe. Wer damit testet, sieht immer alles und hält es für normal. Der Test zählt nur mit einem normalen Nutzer. Das gilt auch, wenn der Agent testet.

Getestet werden nur Tabellen. Dateien wie Bilder oder Dokumente liegen woanders und haben eigene Regeln. Eine abgesicherte Tabelle sagt nichts über die Dateien daneben. Das ist ein zweiter Durchgang mit demselben zweiten Nutzer.

Wo es danach weitergeht

Der Test findet den häufigsten Fall, aber nicht alles. Regeln, die beim Schreiben greifen und beim Lesen nicht. Ansichten, die an den Regeln vorbeigehen, obwohl die Tabelle darunter geschützt ist. Verbindungen, die offen bleiben und dir still auf die Rechnung wachsen.

An diesen Stellen kippen Supabase-Projekte im echten Betrieb, und sie stehen so nicht in der Doku. Im Supabase-Guide liegen sie gesammelt.

Bis dahin reicht ein Handgriff: zweiter Nutzer, alles anzeigen lassen, schauen, was er sieht.