RLS (Sécurité au Niveau des Lignes)
La RLS (Row Level Security, sécurité au niveau des lignes) est un mécanisme de base de données qui filtre les données ligne par ligne selon qui fait la demande. Concrètement, chaque utilisateur ne peut lire ou modifier que les lignes qui lui appartiennent — la règle est appliquée par la base elle-même, pas seulement par le code de l'application.
Quel problème la RLS résout-elle ?
Dans un produit où plusieurs clients partagent la même base de données — le cas de presque tout SaaS —, la question vitale est : comment garantir que le client A ne voie jamais les données du client B ? Sans protection au bon niveau, une simple erreur dans le code (un filtre oublié, une requête mal écrite) peut exposer les données d'autrui. La RLS répond en déplaçant la règle de sécurité dans la base elle-même : on y définit des politiques qui disent « un utilisateur ne peut accéder qu'aux lignes dont il est propriétaire ». Dès lors, même si le code de l'application se trompe, la base refuse de renvoyer ce qui n'appartient pas au demandeur. C'est une protection de dernier rempart, là où les données vivent.
Comment fonctionne la RLS ?
On active la RLS sur une table, puis on y attache des politiques — des règles qui s'appliquent automatiquement à chaque requête. Une politique typique pour une table de projets dirait : « autoriser la lecture d'une ligne uniquement si son champ propriétaire correspond à l'utilisateur connecté ». À partir de là, toute requête sur cette table est silencieusement filtrée par la base : un utilisateur qui demande « tous les projets » ne reçoit que les siens, sans que le code ait à l'expliciter à chaque fois. La force du système est là : la règle est centralisée, appliquée partout, impossible à contourner par oubli. C'est exactement ce qui rend la RLS si adaptée aux applications multi-clients, où une fuite de données entre comptes serait catastrophique.
Pourquoi la sécurité applicative ne suffit-elle pas ?
Parce qu'elle repose sur la perfection du code, à chaque endroit, pour toujours. Filtrer les données « côté application » fonctionne tant qu'aucun développeur n'oublie jamais une condition, qu'aucune nouvelle requête n'échappe à la règle, qu'aucun chemin d'accès n'est négligé. Or les bases de code grandissent, les équipes changent, et l'erreur humaine est inévitable. La RLS ne remplace pas la sécurité applicative — elle la double d'un filet de sécurité au niveau le plus profond. Si une faille passe dans le code, la base reste la dernière ligne de défense. Cette défense en profondeur — plusieurs couches qui se rattrapent — est un principe fondamental dès qu'on manipule des données sensibles. Compter sur une seule couche, c'est parier qu'elle ne faillira jamais.
RLS : un réflexe à avoir dès le départ
Activer la RLS coûte peu au début d'un projet et énormément à rattraper plus tard. Sur une jeune application, il est tentant de « voir plus tard » et de tout filtrer dans le code pour aller vite. Mais une fois la base remplie de données réelles et le code étalé partout, ajouter la RLS devient un chantier risqué. C'est pourquoi nous l'activons systématiquement sur les tables sensibles dès leur création : chaque table de données utilisateur naît avec ses politiques d'accès. Ce réflexe transforme la sécurité d'un correctif anxiogène en propriété native du produit. Pour un fondateur, c'est aussi un argument de confiance : pouvoir affirmer que l'isolation des données est garantie par l'architecture, pas seulement promise par le code.
Le piège des clés qui contournent la RLS
Un point critique, souvent mal compris, mérite toute votre attention : certaines clés d'accès contournent volontairement la RLS. Dans des plateformes comme Supabase, la clé « publique » (anon) respecte les politiques de sécurité au niveau des lignes — c'est elle qui s'utilise côté navigateur, là où elle pourrait être exposée. Mais la clé « de service » (service_role), elle, a tous les droits et ignore la RLS : elle est faite pour les traitements de confiance, côté serveur uniquement. Le piège serait d'utiliser cette clé toute-puissante au mauvais endroit — par exemple côté client — ou de la laisser fuiter : la RLS deviendrait alors un rempart inutile, contourné par la clé elle-même. La règle d'or : la clé de service ne quitte jamais le serveur, et toute opération exposée au public passe par la clé qui respecte la RLS. La sécurité au niveau des lignes ne protège que si l'on ne se sert pas, par mégarde, du passe-partout qui l'annule.
| Code applicatif seul | Avec RLS (base de données) | |
|---|---|---|
| Où vit la règle | Partout dans le code | Au cœur de la base |
| Si un filtre est oublié | Fuite possible entre clients | La base refuse quand même |
| Nombre de couches | Une | Deux (défense en profondeur) |
| À mettre en place | À chaque requête | Une fois, par table |
Les questions fréquentes
Un projet en tête ?
Décrivez-nous votre projet en deux minutes. Réponse sous 24h ouvrées, avec une première lecture concrète.