Supabase RLS erklärt
Was ist Row Level Security in Supabase und wann brauche ich sie?
Row Level Security ist die Zugriffskontrolle direkt in PostgreSQL: sie entscheidet pro Zeile, wer sie lesen oder schreiben darf. In Supabase ist das keine zusätzliche Härtung, sondern die einzige Zugriffskontrolle, die zwischen einer Tabelle im public-Schema und dem Internet steht — denn der anon key, der in jedem Browser-Bundle ausgeliefert wird, darf über PostgREST auf genau dieses Schema zugreifen. Eine Tabelle im public-Schema ohne aktivierte RLS ist damit für jeden lesbar, der die URL des Projekts und den anon key hat — und beides steht im Quelltext jeder Seite.
Warum der anon key kein Geheimnis ist (und trotzdem reicht)
Der anon key ist absichtlich öffentlich. Er identifiziert das Projekt und die Rolle anon, nicht einen Nutzer, und er gehört in den Client — ihn zu verstecken wäre sinnlos, weil der Browser ihn ohnehin senden muss. Genau deshalb ist er auch keine Sicherheitslücke und wird von Sentris nie als solche gemeldet.
Was ihn gefährlich macht, ist nicht der Schlüssel, sondern das, was dahinter offen steht. PostgREST beantwortet mit diesem Schlüssel jede Anfrage, die RLS durchlässt. Ohne RLS lässt RLS alles durch.
RLS einschalten reicht nicht — und schaltet erst einmal alles ab
alter table public.leads enable row level security; aktiviert die Prüfung. Ohne passende Policy ist das Ergebnis: niemand darf etwas, außer der service_role-Key, der RLS grundsätzlich umgeht. Das ist die sichere Richtung, aber es ändert das Verhalten der App sofort — Leseanfragen, die vorher funktionierten, liefern jetzt eine leere Liste.
Die Policy ist der eigentliche Teil der Arbeit, und sie hängt davon ab, wie Ihre Daten gehören. using (auth.uid() = user_id) ist der Normalfall; welche Spalte das bei Ihnen ist, weiß kein Werkzeug von außen.
using (true): der Fehler, der wie eine Lösung aussieht
create policy "…" on public.orders for all using (true); schaltet RLS ein und erlaubt anschließend alles. Das passiert regelmäßig, wenn RLS eingeschaltet wurde, die App daraufhin nichts mehr anzeigte und die schnellste Lösung gesucht war.
Für echte öffentliche Daten — Blogbeiträge, öffentliche Angebote — ist das korrekt. Für alles, was einem Nutzer gehört, ist es ein Leck mit eingeschalteter Prüfung, und es sieht in jedem Dashboard aus wie „RLS aktiv“. Deshalb ist das ein eigener Befund und keine Fußnote.
Prüfen, ohne dem Dashboard zu glauben
Der schnellste Selbsttest: curl "https://<projekt>.supabase.co/rest/v1/<tabelle>?select=*&limit=1" -H "apikey: <anon key>". Kommt eine Zeile zurück, ist die Tabelle für jeden Besucher Ihrer Seite lesbar.
Das ist genau die Anfrage, die Sentris stellt, wenn ein Ziel verifiziert ist: eine Zeile, lesend, mit dem öffentlichen Schlüssel Ihres eigenen Projekts. Aus einem Verdacht wird damit ein Beweis — oder der Befund verschwindet, weil PostgreSQL selbst sagt, dass die Rolle nichts darf.
Sentris prüft diese vier Punkte automatisch
Ein Scan braucht keinen Account und kostet nichts — Sie sehen die Anzahl der Funde, bevor Sie irgendetwas bezahlen. Wie oft wir dabei danebenliegen, steht gemessen und mit Datum unter /precision; das veröffentlicht in diesem Markt sonst niemand. Gerichtsstand Schweiz, AVV und Unterauftragsverarbeiter sind öffentlich einsehbar.
App scannenSentris is evidence of technical measures taken. It is not evidence of GDPR compliance, and nobody selling a tool can issue that.