Supabase RLS prüfen: Policies, Rollen und Mandantentrennung

Sie möchten RLS nicht nur syntaktisch prüfen, sondern Auth, Storage und reale Nutzerwege einbeziehen? WZ-IT übernimmt Supabase Managed Hosting, Migration und Sicherheitsreviews für produktive Anwendungen.

Wer Supabase RLS prüfen möchte, muss zwei Ebenen gemeinsam verstehen: PostgreSQL-Rechte bestimmen, ob eine Rolle eine Operation grundsätzlich ausführen darf. Row Level Security bestimmt anschließend, auf welche Zeilen diese Operation angewendet werden darf.

Fehler entstehen häufig nicht in einer einzelnen Policy, sondern an den Übergängen zwischen Grants, Rollen, Auth-Claims, Views, Functions, Storage und serverseitigen Schlüsseln.

Was RLS in Supabase schützt

Supabase stellt Datenbanktabellen über automatisch erzeugte APIs bereit. Für exponierte Tabellen bildet RLS die zentrale Datenzugriffskontrolle. Typische Regeln sind:

• Nutzer dürfen nur ihr eigenes Profil lesen
• Mandanten sehen ausschließlich ihre eigenen Datensätze
• Rollen dürfen bestimmte Statuswerte verändern
• anonyme Nutzer sehen nur veröffentlichte Inhalte
• Nutzer dürfen Dateien nur in einem eigenen Pfad lesen oder schreiben

RLS ersetzt keine Authentifizierung. Auth stellt Identität und Claims bereit; RLS verwendet diese Informationen in Datenbank-Policies.

1. Angriffs- und Datenfläche inventarisieren

Ein Audit beginnt nicht bei der ersten Policy, sondern bei allen erreichbaren Datenwegen:

Auch nicht direkt im Frontend referenzierte Tabellen können über generische API-Zugriffe erreichbar sein, wenn Schema, Grants und Rollen dies erlauben.

2. Rollen und Schlüssel unterscheiden

Typische Rollen und Kontexte:

• anon für nicht angemeldete Client-Anfragen
• authenticated für angemeldete Nutzer
• service_role für kontrollierte serverseitige Administration
• Datenbankrollen für interne Prozesse oder direkte Verbindungen

Der öffentliche Schlüssel ist nicht geheim. Seine Sicherheit basiert darauf, dass die dadurch verwendete Rolle nur erlaubte Operationen besitzt und RLS greift. Der service_role-Schlüssel ist dagegen hoch privilegiert und darf nie im Browser, Mobile-Bundle oder öffentlich lesbaren Repository stehen.

3. RLS-Status und Grants gemeinsam lesen

Für jede exponierte Tabelle werden geprüft:

• ist RLS aktiviert?
• ist erzwungene RLS für relevante Eigentümerzugriffe nötig?
• welche Rechte haben anon und authenticated?
• existieren alte oder überbreite Grants?
• gibt es Policies für jede tatsächlich benötigte Operation?
• verwenden administrative Prozesse eine Umgehungsrolle?

Zu breite Grants werden nicht automatisch durch eine gute SELECT-Policy für alle Operationen repariert. Umgekehrt macht eine Policy ohne benötigtes Tabellenrecht die Anwendung funktionslos.

4. USING und WITH CHECK korrekt einsetzen

Policies unterscheiden vorhandene und neue Zeilenzustände:

• USING filtert Zeilen, die SELECT, UPDATE oder DELETE sehen beziehungsweise bearbeiten dürfen.
• WITH CHECK prüft neue Werte bei INSERT und UPDATE.

Ein typischer Fehler ist eine UPDATE-Policy, die das Lesen einer eigenen Zeile erlaubt, aber nicht verhindert, dass die Mandanten-ID beim Schreiben geändert wird. Für Schreibvorgänge müssen daher alter Zugriff und neuer Zustand betrachtet werden.

5. Auth-Claims und Null-Fälle

Die offizielle Supabase-Dokumentation weist darauf hin, dass die Auth-Nutzer-ID bei nicht angemeldeten Anfragen null ist. Policies sollten den gewünschten Auth-Zustand ausdrücklich abbilden.

Zu prüfen sind:

• Verhalten ohne Login
• abgelaufene oder ungültige Tokens
• E-Mail- oder Rollen-Claims
• veraltete Claims nach Rollenänderung
• Nutzer-Metadaten, die vom Nutzer selbst veränderbar sein können
• Mandantenwechsel oder mehrere Mitgliedschaften

Sicherheitsentscheidungen dürfen nicht auf frei änderbaren Client-Daten beruhen.

6. Mandantentrennung fachlich testen

Für ein Mehrmandantensystem reicht ein Testkonto nicht. Eine minimale Matrix verwendet:

• Nutzer A in Mandant A
• Nutzer B in Mandant A mit anderer Rolle
• Nutzer C in Mandant B
• anonymen Zugriff
• serverseitigen Prozess

Getestet werden:

Negativtests sind wichtiger als ein pauschaler „API funktioniert“-Test.

7. Views und Functions kontrollieren

Views und Datenbankfunktionen können mit anderen Rechten als der aufrufende Nutzer laufen. Zu prüfen sind:

• Eigentümer und Ausführungsmodus
• Suchpfad und Schema-Auflösung
• ausführbare Rollen
• dynamisches SQL
• Eingabevalidierung
• Zugriff auf Tabellen hinter RLS
• unbeabsichtigte Datenaggregation

Security-Definer-Funktionen sind nicht grundsätzlich falsch. Sie benötigen aber einen engen Zweck, festgelegten Suchpfad, minimale Rechte und gezielte Tests.

8. Storage-Policies einbeziehen

Supabase Storage verwendet Tabellen und RLS-Policies für Objektzugriffe. Ein Audit prüft:

• öffentliche und private Buckets
• Pfadaufbau und Eigentümerlogik
• Upload, Read, Update und Delete getrennt
• Content-Type- und Größenbeschränkungen
• signierte URLs
• serverseitige Uploads
• verwaiste Metadaten oder Dateien

Eine sichere Anwendungstabelle garantiert noch keine sicheren Dateien.

9. Edge Functions und Backends

Serverseitige Komponenten dürfen einen Benutzer-Token weiterreichen und damit dieselbe RLS verwenden. Verwenden sie service_role, tragen sie die Autorisierungslogik selbst.

Prüffragen:

• Ist service_role wirklich erforderlich?
• Wird die Nutzeridentität vor administrativer Aktion verifiziert?
• Kann der Client Objekt- oder Mandanten-IDs manipulieren?
• Werden Secrets geloggt?
• Sind Webhooks authentisiert und wiederholungssicher?

10. Wiederholbare RLS-Review-Gates

Ein einmaliges Audit verliert mit jeder Schemaänderung an Wert. RLS-Tests gehören deshalb in Migrationen und Releases:

1. neue Tabelle standardmäßig nicht exponieren
2. Grants bewusst setzen
3. RLS aktivieren und Policies versionieren
4. Rollen- und Mandantentests automatisieren
5. Negativfälle bei jeder Änderung ausführen
6. service_role-Nutzung inventarisieren
7. Befunde mit Schweregrad und Verantwortlichem dokumentieren

Quellen

• Supabase: Row Level Security
• Supabase: Auth und RLS
• Supabase: Storage Access Control
• PostgreSQL: Row Security Policies