RLS an heißt nicht abgesichert

Im Supabase-Dashboard steht bei deiner Tabelle ein grünes “RLS enabled”. Row Level Security ist 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 ist fast immer derselbe, und er ist völlig logisch.

Supabase warnt dich, dass eine Tabelle ohne RLS öffentlich lesbar ist. Du gibst die Warnung an die KI weiter. Die schaltet RLS ein. Danach funktioniert deine App nicht mehr, weil ohne Policy nichts mehr durchkommt. Du meldest den Fehler. Die KI schreibt eine Policy, die das Problem löst.

Die schnellste Policy, die jedes Problem löst, ist die, die alles durchlässt:

create policy "Enable read access for all users"
on public.profiles for select
using (true);

Die App läuft wieder. Die Warnung ist weg. Das Häkchen ist grün. Und using (true) heißt: jeder darf jede Zeile lesen.

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

Der öffentliche Schlüssel in deinem Frontend ist mit Absicht öffentlich. Er steht in deinem JavaScript, jeder Besucher kann ihn im Browser auslesen, und das ist kein Fehler. Supabase sagt das selbst so: Der Schlüssel identifiziert dein Projekt, er schützt es nicht.

Was schützt, ist die Policy. Sonst nichts.

Deshalb ist using (true) kein kleiner Schönheitsfehler. Es ist der Zustand, den du vorher hattest, nur mit einem grünen Häkchen davor.

Der Test: hol dir einen zweiten Nutzer

Das ist der eigentliche Handgriff, und er dauert drei Minuten.

1. Leg einen zweiten Account in deiner App an. Nicht deinen Admin-Account, nicht den, mit dem du entwickelst. Einen frischen, der nichts besitzt.
2. Melde dich damit an und hol dir sein Token.
3. Frag damit deine Tabelle ab, ohne Filter, ohne where. Einfach alles.
4. Zähl die Zeilen.

curl "https://<projekt>.supabase.co/rest/v1/profiles?select=*" \
  -H "apikey: <dein-anon-key>" \
  -H "Authorization: Bearer <token-des-zweiten-nutzers>"

Kommt mehr zurück als das, was diesem Nutzer gehört, ist die Tabelle offen. Kommt nur seine eigene Zeile, greift die Policy.

Das ist der ganze Test. Kein Werkzeug, kein Abo, keine Analyse.

Warum du das nicht durch Lesen findest

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

Die KI wird dir das auch nicht sagen. Sie hat getan, worum du gebeten hast: die Fehlermeldung ist weg. Dass sie dabei die Tür aufgelassen hat, war nicht Teil der Aufgabe. Deswegen prüfst du durch Ausführen und nicht durch Lesen.

Zwei Stellen, an denen derselbe Test danebengeht

Du testest mit dem falschen Schlüssel. Der Service-Schlüssel umgeht jede Policy, das ist seine Aufgabe. Wer damit testet, bekommt immer alles zurück und hält es für normal. Der Test zählt nur mit dem öffentlichen Schlüssel plus Nutzer-Token.

Du testest nur Tabellen. Dateien liegen in Buckets, und Buckets haben ihre eigenen Regeln. Eine abgesicherte Tabelle sagt nichts über die Bilder, die daneben liegen. Das ist ein zweiter Durchgang mit demselben zweiten Nutzer.

Wo es danach weitergeht

Der Test oben findet den häufigsten Fall. Er findet nicht alles. Policies, die beim Schreiben greifen und beim Lesen nicht. Views, die an der Policy vorbeigehen, obwohl die Tabelle darunter geschützt ist. Verbindungen, die offen bleiben und dir still auf die Rechnung wachsen.

Das sind die Stellen, an denen Supabase-Projekte in Produktion tatsächlich kippen, und sie stehen so nicht in der Doku. Im Supabase-Guide liegen sie gesammelt, mit den Policies, die wirklich absichern, statt nur zu existieren.

Bis dahin reicht der eine Handgriff: zweiter Nutzer, keine Filter, Zeilen zählen. Wenn du diese Woche nur eine Sache prüfst, dann die.