Row Level Security : filtrer par ligne

La RLS fait appliquer par la base la règle « chaque utilisateur ne voit que ses données » : un garde-fou en profondeur pour les applications multi-locataires.

ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

CREATE POLICY isolation_locataire ON documents
    USING (locataire_id = current_setting('app.locataire_id')::bigint)
    WITH CHECK (locataire_id = current_setting('app.locataire_id')::bigint);

L'application indique le locataire courant au début de chaque transaction :

BEGIN;
SET LOCAL app.locataire_id = '42';     -- valable pour la transaction seulement
SELECT * FROM documents;               -- ne renvoie que les documents du locataire 42
COMMIT;

Points d'attention#

• Le propriétaire de la table contourne la RLS, sauf avec ALTER TABLE ... FORCE ROW LEVEL SECURITY. L'application ne doit pas se connecter avec le propriétaire.
• USING filtre les lignes visibles ; WITH CHECK valide celles qu'on écrit.
• Avec un pooleur en mode transaction, utilisez SET LOCAL (et non SET) pour que la valeur ne fuie pas vers une autre session.
• Les politiques ajoutent un coût de planification : indexez locataire_id et mesurez.

Cas pratique : dans un SaaS multi-locataires, une seule clause WHERE locataire_id = ? oubliée dans un endpoint expose les données d'un client à un autre. La RLS transforme cette erreur (fréquente) en résultat vide plutôt qu'en fuite de données.