Supabase-RLS-Policies richtig testen: Warum Automatisierung Sicherheit sichert

Row-Level Security (RLS) ist das Rückgrat der Datensicherheit in modernen Datenbanken wie Supabase. Doch was passiert, wenn die Policies fehlerhaft sind? Häufig bleibt das unbemerkt, bis es zu spät ist. Die neue Open-Source-Lösung rlsautotest ändert das – sie generiert automatisch Tests und Testdaten direkt aus deinen RLS-Policies und deckt so potenzielle Sicherheitsrisiken auf, bevor sie zum Problem werden.

Warum RLS-Policies oft ungetestet bleiben – und welche Risiken damit einhergehen

RLS-Policies in Supabase oder PostgreSQL entscheiden, wer auf welche Daten zugreifen darf. Doch hier liegt das Problem: Fehlerhafte Policies führen nicht zu Fehlermeldungen, sondern liefern schlicht die falschen Daten zurück.

• Zu restriktive Policies führen dazu, dass legitime Nutzer keine Daten abrufen können – die Anwendung wirkt gebrochen.
• Zu permissive Policies ermöglichen unbefugten Zugriff auf sensible Daten, was zu Datenlecks führt.

Beide Szenarien verursachen keine Ausnahmen oder Warnungen. Stattdessen merken Entwicklerteams oft erst durch verunsicherte Nutzer oder externe Sicherheitsberichte, dass etwas nicht stimmt. Selbst wenn Policies im SQL-Editor funktionieren, ist das kein verlässlicher Test: Der SQL-Editor umgeht RLS, sodass die Policies in der Praxis nie getestet werden.

Manuelle Tests: Warum sie scheitern – und was wirklich geprüft werden muss

Die offizielle Supabase-Dokumentation räumt ein, dass das Schreiben von pgTAP-Tests für RLS-Policies für viele Webentwickler unzugänglich ist. Ein manueller Test erfordert folgende Schritte:

• Erstellung mehrerer Nutzerrollen (Besitzer, Gast, authentifizierter Nutzer, Rolleninhaber)
• Einspielen von Testdaten, die verschiedenen Nutzern zugeordnet sind
• Wechsel der Identität durch Anpassung von JWT-Claims und Rollen
• Ausführung von SELECT-, INSERT-, UPDATE- und DELETE-Operationen für jede Rolle
• Überprüfung, welche Daten jede Rolle sehen und verändern darf

Diese Prozedur muss für jede Tabelle und jede Policy wiederholt werden. Doch selbst wenn diese Tests durchgeführt werden, hängt die Aussagekraft stark von den verwendeten Testdaten ab. Ein Test, der nur eine leere Tabelle prüft, liefert zwar ein grünes Ergebnis – beweist aber nichts.

Ein aussagekräftiger RLS-Test muss aus Sicht jeder Nutzerrolle folgende Punkte überprüfen:

• Der Besitzer sieht und kann seine eigenen Daten ändern.
• Andere Nutzer oder Tenants sehen diese Daten nicht.
• Anonyme Nutzer (anonym) erhalten keinen Zugriff.
• Rolleninhaber erhalten genau die Zugriffe, die ihnen zugewiesen sind.

Zusätzlich muss zwischen zwei Arten von Zugriffsverweigerungen unterschieden werden:

• Filterung auf Zeilenebene → Keine Daten werden zurückgegeben.
• Fehlende Berechtigung → Permission-Error wird ausgelöst.

Automatisierung als Lösung: Wie rlsautotest RLS-Policies überprüft

Angesichts des hohen Aufwands für manuelle Tests hat der Entwickler hinter rlsautotest eine Automatisierungslösung geschaffen. Das Tool generiert sowohl Testdaten als auch pgTAP-Tests direkt aus den im Datenbankkatalog hinterlegten Policies. Dadurch entfällt der manuelle Aufwand – und die Tests werden reproduzierbar und zuverlässig.

Installation und erste Schritte

Die Einrichtung von rlsautotest ist unkompliziert:

pip install rlsautotest

Anschließend kann das Tool mit einem Datenbank-URL-Parameter gestartet werden. Beispiel für einen schnellen HTML-Report:

rlsautotest --db-url "$DATABASE_URL" --schema public --html rls-report.html

Alternativ kann eine native pgTAP-Testsuite generiert werden, die direkt in CI-Pipelines integriert werden kann:

rlsautotest --db-url "$DATABASE_URL" --schema public --emit supabase/

So liest sich der generierte Report

Der Report zeigt eine klare Übersicht der Berechtigungen für jede Nutzerrolle. Ein Beispiel:

notes    SELECT    INSERT    UPDATE    DELETE
service_role    ✓    ✓    ✓    ✓
authenticated, authorized    ✓    ✓    ✓    ✓
authenticated, not authorized    ·    ·    ·    ·
anon    ·    ·    ·    ·

Ziel ist es, ✗-Symbole zu finden, wo ein ✓ erwartet wird – etwa wenn ein anonymer Nutzer unerwartet Schreibrechte erhält. Das Tool markiert zudem unsichere Bereiche, die nicht zuverlässig getestet werden können.

Der kritische Fehler, den Entwickler oft übersehen

Ein häufiger Fallstrick bei der Konfiguration von RLS-Policies sind mehrere permissive UPDATE-Policies, die sich gegenseitig beeinflussen. Betrachten wir folgende Policy-Struktur:

• Policy 1: Erlaubt UPDATE nur für Nutzer mit Rolle admin und beschränkt den Wert auf status = 'approved'.
• Policy 2: Erlaubt UPDATE nur für Nutzer mit Rolle editor und beschränkt den Wert auf status = 'draft'.

Auf den ersten Blick scheinen beide Policies korrekt zu sein. Doch hier liegt der Fehler: PostgreSQL kombiniert die WITH CHECK-Bedingungen aller permissiven Policies mit einem logischen ODER. Das bedeutet, ein Nutzer mit Rolle editor kann einen Datensatz auf den Status approved setzen – obwohl seine Policy das eigentlich verbietet. Die eigentliche Berechtigungsprüfung (USING) wird ignoriert, sobald eine der Policies greift.

rlsautotest erkennt solche Lücken, indem es die möglichen Wertebereiche für jede Nutzerrolle systematisch durchgeht und genau aufzeigt, welche verbotenen Werte trotzdem gesetzt werden können.

Was rlsautotest NICHT leistet – und warum das bewusst so ist

Das Tool überprüft nicht, ob die Policies deinen ursprünglichen Absichten entsprechen – sondern nur, ob sie technisch korrekt umgesetzt sind. Das bedeutet:

• Eine falsche, aber konsistente Policy wird als „sicher“ markiert.
• Fehlende Policies werden als blockiert angezeigt, sofern nicht explizit aktiviert.
• Policies, die auf undurchsichtige Funktionen verweisen, werden als solche gemeldet – nicht künstlich als getestet markiert.

Ein Test, der fälschlicherweise grün markiert, was er nicht überprüfen kann, ist schlimmer als gar kein Test. Deshalb verzichtet rlsautotest bewusst auf solche falschen Bestätigungen.

Fazit: RLS-Sicherheit mit wenig Aufwand nachhaltig gewährleisten

Row-Level Security ist ein mächtiges Werkzeug, um die Datensicherheit zu gewährleisten – doch nur, wenn die Policies tatsächlich korrekt funktionieren. Da manuelle Tests fehleranfällig und zeitaufwendig sind, bietet rlsautotest eine effiziente und zuverlässige Alternative.

Probiere das Tool an einer Testdatenbank aus, um deine Policies zu überprüfen. Ein einziger Befehl genügt, um einen detaillierten Report zu erhalten. Im schlimmsten Fall bestätigst du damit, dass deine Policies korrekt sind. Im besten Fall entdeckst du Lücken, bevor sie zu einem echten Sicherheitsrisiko werden.

Die Zukunft der RLS-Tests liegt in der Automatisierung – und mit rlsautotest steht ein mächtiges Werkzeug bereit, um diese Zukunft zu gestalten.