Client, prestataire, administrateur : sur une même base, l'isolation ne doit pas reposer sur le code applicatif. Le Row-Level Security la rend structurelle.
Une marketplace ou un produit multi-rôle partage une seule base entre des acteurs aux droits différents. Si l'isolation vit dans les requêtes applicatives, une seule oublie suffit à fuiter.
Mettre la règle dans la base
Le Row-Level Security applique la politique d'accès au niveau des lignes, dans PostgreSQL. Même requête, mais chaque rôle ne voit que ses données. La sécurité ne dépend plus de la discipline du développeur.
On écrit des politiques par table et par opération : lecture, écriture, suppression. Le rôle et l'identité sont portés par le jeton, vérifiés côté base.
Les pièges
Les RLS mal pensées cassent en silence ou ouvrent trop. Il faut tester chaque politique avec chaque rôle, et se méfier des accès service qui contournent les règles. La clé de service ne doit jamais toucher le front.
Bien posé, ce modèle survit aux refontes applicatives : la garantie est dans la base, pas dans la couche du dessus.