Supabase Row Level Security: Warum sie die Zugriffskontrolle verändert

Die meisten Datenlecks in Mehrmandanten-Anwendungen entstehen nicht durch ausgefeilte Angriffe, sondern durch eine vergessene Zeile. Ein Entwickler baut einen neuen Endpoint, schreibt die Query und vergisst das where user_id = .... Ab diesem Moment sieht Nutzer A die Daten von Nutzer B.

Genau hier setzt Supabase Row Level Security an. Statt die Zugriffskontrolle in jedem Endpoint neu zu formulieren, sitzt sie als Regel im Fundament der Datenbank. Das klingt nach einem Entwicklerdetail. Es ist in Wirklichkeit eine Entscheidung über Risiko und Entwicklungsgeschwindigkeit, und sie gehört auf den Tisch von CIOs und CTOs, nicht nur in den Pull Request.

Die klassische Antwort auf Mandantentrennung ist Middleware. Ein Backend-Endpoint prüft die User-ID, filtert jede Query, und das wiederholt sich für jeden neuen Endpoint. Dieser Ansatz ist fehleranfällig, schwer testbar und muss bei jedem Feature neu durchdacht werden. Die Sicherheit hängt an der Disziplin jedes einzelnen Entwicklers an jedem einzelnen Tag. Ein vergessener Filter genügt für ein Datenleck.

RLS dreht das Modell um. Die Zugriffsregel wird einmal als Policy auf einer Tabelle geschrieben, und Postgres erzwingt sie danach für jeden Client automatisch. Auch dann, wenn ein Entwickler den Filter im Anwendungscode vergisst. Aus select where user_id = aktuellerNutzer in jedem Endpoint wird eine einzige Regel in der Datenbank.

Ein konkretes Beispiel. Eine Projektmanagement-App, jeder Nutzer soll nur seine eigenen Projekte sehen. Sie aktivieren RLS auf der Tabelle und schreiben eine Policy, die festlegt: Eine Zeile ist nur sichtbar, wenn ihre user_id der ID des angemeldeten Nutzers entspricht. Ab diesem Moment ist die Zugriffskontrolle eine Eigenschaft der Tabelle, nicht eine Verantwortung des nächsten Endpoints. Wer wissen will, was Supabase darunter überhaupt ist, findet das im Grundlagenartikel Was ist Supabase?.

Der entscheidende Punkt für Entscheider: Eine ganze Fehlerklasse verschwindet. Nicht weil das Team disziplinierter arbeitet, sondern weil die Datenbank den Fehler strukturell nicht mehr zulässt. Das ist der Unterschied zwischen "wir achten darauf" und "es kann nicht passieren".

RLS ist kein Supabase-Feature, sondern eine native Funktion von Postgres. Supabase macht sie nur komfortabel nutzbar und verdrahtet sie mit der Authentifizierung. Die Zugriffsregel läuft damit auf derselben Ebene wie die Daten selbst, ausgewertet vom Query-Planer.

Das hat eine Konsequenz, die in Architektur-Diskussionen oft untergeht: Es gibt keinen Umweg an der Regel vorbei. Egal ob die Abfrage aus dem Web-Frontend, einer mobilen App oder einem Drittsystem kommt, sie trifft dieselbe Policy. Die Postgres-Dokumentation zu CREATE POLICY beschreibt das Verhalten präzise: Die Bedingung wird als zusätzliches Prädikat in jede Abfrage eingebaut, transparent für den Client.

Für die Zugriffskontrolle in der Datenbank bedeutet das eine andere Vertrauensgrenze. Bei reiner Anwendungslogik vertrauen Sie darauf, dass jeder Pfad zur Datenbank die Filter korrekt setzt. Bei RLS vertrauen Sie der Datenbank, und die Anwendung kann den Filter gar nicht mehr umgehen, solange sie mit dem normalen Nutzer-Token arbeitet. Die Sicherheit wird von einer Eigenschaft des Codes zu einer Eigenschaft des Datenmodells.

Drei Effekte sind relevant, wenn Sie eine Investitionsentscheidung rechtfertigen müssen.

Erstens, weniger Bugs und strukturell weniger Sicherheitsrisiko. Der vergessene Filter wird unmöglich, nicht unwahrscheinlich. Das ist ein Argument, das vor einem Vorstand trägt, weil es eine Aussage über die Architektur ist, nicht über die Sorgfalt eines Teams.

Zweitens, schnellere Entwicklung. Neue Features erben die Zugriffskontrolle aus der Datenbankschicht. Das Team schreibt weniger Boilerplate, und jeder neue Endpoint ist von Anfang an abgesichert, ohne dass jemand daran denken muss. Sicherheit als Standardzustand statt als Zusatzaufgabe beschleunigt die Auslieferung messbar.

Drittens, Skalierung. Dieselbe Policy gilt für zehn wie für hunderttausend Nutzer. Es gibt keine wachsende Matrix aus Endpoints und Filterbedingungen, die mit dem Erfolg des Produkts mitwächst und mitkippt. Das Operating Model bleibt über die Zeit stabil.

Der Punkt, an dem RLS am deutlichsten wird, ist Mandantenfähigkeit. Ein typisches Multitenancy-SaaS hat Organisationen, in denen Nutzer mit Rollen sitzen, etwa Owner, Admin und Member. Diese Struktur lässt sich direkt in Policies abbilden.

Eine Zeile gehört zu einer Organisation, ein Nutzer gehört über eine Zwischentabelle zu einer oder mehreren Organisationen, und die Policy verknüpft beides: Sichtbar ist eine Zeile nur, wenn der angemeldete Nutzer Mitglied der zugehörigen Organisation ist. Rollen kommen als zusätzliche Bedingung dazu, wenn etwa nur Admins bestimmte Datensätze ändern dürfen.

Das Ergebnis ist eine harte Mandantentrennung: Nutzer aus Firma A sehen nie Daten von Firma B. Diese Garantie liegt nicht in einer Middleware-Schicht, die jemand pflegen, testen und bei jedem Feature erneut korrekt verdrahten muss, sondern in der Datenbank. Für ein SaaS-Produkt, dessen ganzes Geschäftsmodell auf der Trennung der Kundendaten beruht, ist das der pragmatischste und zugleich sicherste Weg, den ich kenne.

Wer von Firebase kommt, sollte einen Punkt einplanen. In Supabase ersetzt RLS die Firestore Security Rules, aber die Modelle sind nicht deckungsgleich. Firestore-Regeln sind pfadbasiert, RLS sind SQL-Policies pro Tabelle. Das ist ein Neudenken des Sicherheitsmodells, kein Suchen-und-Ersetzen, und genau diesen Schritt unterschätzen Teams bei der Migration von Firebase zu Supabase regelmäßig.

Wer RLS als Sicherheitsgarantie verkauft, hat es nicht verstanden. Es nimmt eine bestimmte Fehlerklasse aus dem Spiel, aber es eröffnet andere, wenn man unaufmerksam ist.

Policies müssen durchdacht sein. Eine falsch geschriebene Policy erlaubt zu viel oder zu wenig, und beides fällt oft erst spät auf. Zu viel bedeutet ein Datenleck, zu wenig bedeutet eine kaputte Anwendung. Policies gehören deshalb getestet, am besten mit Negativtests, die belegen, dass ein Nutzer eben nicht sieht, was er nicht sehen darf.

Zwei Mechanismen umgehen RLS bewusst, und beide muss man kennen. SECURITY-DEFINER-Funktionen, in Supabase als RPCs aufgerufen, laufen mit den Rechten des Definierers und können RLS gezielt aushebeln. Das ist manchmal genau gewollt, etwa für administrative Operationen, aber es muss kontrolliert und sichtbar eingesetzt werden. Der service_role-Key umgeht RLS vollständig. Er ist für serverseitige Aufgaben gedacht und darf niemals ins Frontend gelangen. Ein service_role-Key im Browser-Code ist der schwerwiegendste Fehler, den man mit Supabase machen kann, und er macht jede Policy wertlos. Die Supabase-Dokumentation zu Row Level Security ist an dieser Stelle eindeutig.

Außerdem ersetzt RLS keine Eingabevalidierung. Es entscheidet, wer welche Zeilen sieht und ändert, nicht ob die Eingaben einer Geschäftslogik genügen. Und komplexe Policies können Performance kosten, wenn pro Zeile teure Unterabfragen ausgewertet werden. Das ist beherrschbar, aber es ist eine Designaufgabe, kein Selbstläufer.

Aktivieren Sie RLS ab Tag 1, auch mit einfachen Policies. Nachträglich eingebaute Sicherheit ist immer teurer und unzuverlässiger als von Anfang an mitgedachte. Eine Tabelle ohne aktiviertes RLS in einem Mandanten-System ist eine offene Tür, und je länger das System läuft, desto mehr Code stützt sich auf diese offene Tür.

Behandeln Sie die Frage nicht als Implementierungsdetail des Entwicklungsteams, sondern als Architekturentscheidung mit direkter Wirkung auf Vendor Risk, Compliance und Auslieferungsgeschwindigkeit. RLS verschiebt die Vertrauensgrenze an die richtige Stelle: in die Datenbank, wo die Daten ohnehin liegen. Das ist kein Zaubertrick, der Eingabevalidierung, saubere Schlüsselverwaltung und getestete Policies ersetzt. Aber es nimmt Ihnen die teuerste und peinlichste Fehlerklasse strukturell ab, und das ist mehr, als die meisten Sicherheitsmaßnahmen leisten. Wer die Plattform als Ganzes bewertet, sollte RLS als einen der Gründe verbuchen, warum sich Supabase für ernsthafte Mehrmandanten-Produkte rechnet, wie wir es in unserer Einordnung als Supabase-Agentur ausführen.