Postgres RLS in der Praxis: drei Stolperfallen

Row-Level Security ist für mandantenfähige Anwendungen ein großartiges Sicherheitsnetz: Die Datenbank selbst erzwingt, dass jede Abfrage nur die Zeilen des aktuellen Mandanten sieht. Auf dem Papier klingt das simpel. In der Praxis sind wir über drei Stolperfallen gestolpert, die wir gern früher gekannt hätten. Erstens: Der Tabellen-Eigentümer umgeht RLS standardmäßig. Wer seine Anwendung mit demselben Datenbank-Benutzer betreibt, der auch die Migrationen ausführt, hat RLS faktisch ausgeschaltet. Die Lösung ist ein separater, unprivilegierter Anwendungs-Benutzer — und ein Test, der genau das nachweist. Zweitens: Vergessene Kontext-Variablen fallen nicht auf — sie liefern einfach null Zeilen. Das klingt sicher, ist aber tückisch: Ein Handler ohne gesetzten Mandanten-Kontext wirkt wie ein leerer Datenbestand, nicht wie ein Fehler. Wir loggen deshalb jede Transaktion ohne gesetzte Kontext-Variable als Warnung. Drittens: Es gibt legitime Pfade an RLS vorbei — etwa wenn ein eingeladener Benutzer seine allererste Mitgliedschaft anlegt und die Policy ihn naturgemäß noch nicht kennt. Diese Bypass-Stellen gehören explizit dokumentiert und auf eine Handvoll begründeter Fälle begrenzt, sonst wuchern sie. Unterm Strich: RLS hat uns bereits zweimal vor einem echten Datenleck bewahrt, das ein Anwendungs-Bug sonst verursacht hätte. Die Stolperfallen sind real, aber der Tausch lohnt sich.