Supabase Row-Level Security prüfen: Gibt Ihre App Daten preis?

Eine Supabase-App spricht direkt aus dem Browser mit der Datenbank. Dafür steckt ein öffentlicher Schlüssel im Frontend – der anon- bzw. neue publishable-Key. Das ist so gewollt. Sicher ist es aber nur, wenn die Datenbank selbst entscheidet, wer welche Zeile sehen darf. Genau das macht Row-Level Security (RLS).

Fehlt RLS auf einer Tabelle, kann jeder mit dem öffentlichen Schlüssel ihren gesamten Inhalt lesen – und oft auch ändern. Bei Lovable-Projekten war das so verbreitet, dass es eine eigene Sicherheitsmeldung bekam: CVE-2025-48757, Schweregrad 9,3 von 10 (Lovable bestreitet die Einstufung).

Schritt 1: Security Advisor öffnen

Im Supabase-Dashboard unter Advisors → Security Advisor. Supabase prüft dort Ihre Datenbank automatisch. Achten Sie besonders auf diese Meldungen:

• RLS Disabled in Public – eine Tabelle im öffentlichen Schema hat keine Row-Level Security. Das ist der kritische Fall.
• RLS Enabled No Policy – RLS ist an, aber es gibt keine Regel. Dann sieht niemand etwas – sicher, aber oft ein Hinweis, dass die App anders funktioniert als gedacht.
• Security Definer View – eine View läuft mit den Rechten ihres Erstellers und umgeht damit RLS.

Jede Meldung mit Stufe «Error» gehört vor dem Livegang behoben.

Schritt 2: Selbst abfragen wie ein Fremder

Den öffentlichen Schlüssel und die Projekt-Adresse finden Sie in den Projekteinstellungen unter API – oder im Browser in den Netzwerk-Anfragen Ihrer App. Dann fragen Sie eine Tabelle ab, ohne angemeldet zu sein:

curl 'https://IHR-PROJEKT.supabase.co/rest/v1/kunden?select=*' \
  -H "apikey: IHR_OEFFENTLICHER_SCHLUESSEL"

Das Ergebnis lesen Sie so:

Antwort	Bedeutung
[]	Gut: RLS ist aktiv und gibt anonymen Nutzern nichts heraus.
Daten	Kritisch: Die Tabelle ist öffentlich lesbar.
Fehler «permission denied»	Gut: Die Rolle hat gar keinen Zugriff.

Wiederholen Sie das für jede Tabelle mit Personendaten, Bestellungen, Nachrichten oder Zahlungsinformationen.

Schritt 3: Mit zwei Konten gegeneinander testen

Leere Antworten für Anonyme reichen nicht. Die häufigere Lücke ist eine zu grosszügige Regel für Angemeldete – etwa using (true) oder eine Regel, die nur prüft, ob jemand eingeloggt ist.

1. Legen Sie zwei Testkonten an, A und B.
2. Erstellen Sie mit Konto A ein paar Datensätze.
3. Melden Sie sich mit Konto B an und rufen Sie die Daten ab – in der App oder per curl mit dem Zugriffstoken von B im Header Authorization: Bearer ….

Sieht B die Daten von A, ist die Regel zu offen.

Schritt 4: Regeln richtig setzen

Eine typische, sichere Regel für Daten, die einem Benutzer gehören:

alter table public.notizen enable row level security;

create policy "Eigene Notizen lesen"
  on public.notizen for select
  to authenticated
  using ((select auth.uid()) = user_id);

create policy "Eigene Notizen anlegen"
  on public.notizen for insert
  to authenticated
  with check ((select auth.uid()) = user_id);

Wichtig sind beide Teile: using regelt, was jemand sehen und ändern darf, with check, was er schreiben darf. Fehlt with check, kann ein Benutzer Daten im Namen eines anderen anlegen. Für Firmen-Apps mit mehreren Benutzern pro Kunde prüft die Regel statt der Benutzer-ID die Zugehörigkeit zur Organisation.

Was sonst noch auffällt

• Service-Schlüssel im Frontend. Der service_role- bzw. secret-Key umgeht RLS vollständig. Er darf nie im Browser-Code stehen. Steht er dort, sofort im Dashboard ersetzen.
• Views und Funktionen. Views sollten mit security_invoker = true angelegt sein. Datenbankfunktionen mit security definer laufen mit Admin-Rechten und brauchen eigene Prüfungen.
• Storage. Datei-Uploads haben eigene Regeln auf storage.objects. Ein öffentlicher Bucket macht jede Datei für jeden abrufbar, der die Adresse kennt.
• Edge Functions. Prüfen Sie, ob jede Funktion das Token des Aufrufers verifiziert, bevor sie mit erhöhten Rechten arbeitet.

Wenn Sie etwas gefunden haben

Gehen Sie davon aus, dass die Daten bereits abgerufen werden konnten. Schliessen Sie die Lücke, ersetzen Sie betroffene Schlüssel, und prüfen Sie mit einer Fachperson, ob eine Meldepflicht besteht – in der Schweiz nach dem Datenschutzgesetz bei hohem Risiko an den EDÖB.

Und weil RLS selten das einzige Thema ist: In den 10 häufigsten Sicherheitslücken in KI-Code finden Sie die anderen Kandidaten.