Glossaire
RLS (Row Level Security)
Mécanisme de contrôle d'accès au niveau des lignes d'une base de données. Le RLS permet de restreindre les données visibles par chaque utilisateur, directement au niveau de la base. C'est une brique essentielle pour les applications utilisant Supabase ou PostgreSQL. Dans un SIRH, une RLS mal configurée permet à un salarié de consulter les bulletins de paie ou les évaluations d'autres employés.
Le RLS, pilier du multi-tenant sur Supabase et PostgreSQL
Le Row Level Security est un mécanisme de PostgreSQL qui filtre les lignes accessibles selon des politiques SQL attachées à chaque table. Sur Supabase, c'est LE mécanisme de sécurité central : le client frontend parle directement à la base via l'API auto-générée, donc sans RLS correctement configuré, chaque table est lisible ou modifiable par n'importe quel utilisateur authentifié — voire anonyme. Pour un SaaS RH construit sur Supabase, les politiques RLS sont littéralement ce qui sépare les données d'une entreprise cliente de celles des autres.
Les erreurs RLS que nous trouvons le plus souvent
Nos audits Supabase retrouvent régulièrement les mêmes schémas : tables sans RLS activé (accessibles via l'API REST publique), politiques écrites pour SELECT mais oubliées pour UPDATE ou DELETE, politiques basées sur une colonne modifiable par l'utilisateur lui-même, vues et fonctions RPC qui contournent le RLS (SECURITY DEFINER), et buckets Storage dont les politiques ne suivent pas celles des tables. Une seule table oubliée suffit : la liste des salariés, des candidatures ou des documents devient publique.
Comment CleanIssue audite vos politiques RLS
En conditions réelles, avec des comptes de test dans plusieurs tenants, nous vérifions chaque table exposée par l'API : lecture croisée, écriture croisée, escalade via RPC et Edge Functions, cohérence entre RLS des tables et policies Storage. Le rapport liste chaque table avec son niveau de protection réel — pas celui supposé — et les politiques SQL à corriger, dans un format directement actionnable par votre équipe.
Questions fréquentes
Le RLS est-il activé par défaut sur Supabase ?
Non pour les tables créées en SQL brut : il faut l'activer explicitement (ALTER TABLE ... ENABLE ROW LEVEL SECURITY) puis écrire des politiques. Le dashboard Supabase alerte sur les tables exposées sans RLS, mais l'alerte est souvent ignorée en phase de développement rapide, puis oubliée en production.
Le RLS suffit-il à sécuriser un SaaS multi-tenant ?
C'est la fondation, mais pas la totalité : il faut aussi couvrir les politiques Storage, les fonctions RPC et Edge Functions (qui peuvent s'exécuter avec des privilèges élevés), la clé service_role qui contourne tout le RLS, et la logique métier côté serveur. Un audit vérifie l'ensemble de la chaîne, pas seulement les tables.
Comment tester ses politiques RLS ?
Créez des utilisateurs de test dans des organisations différentes et tentez systématiquement lecture, écriture et suppression croisées sur chaque table via l'API. Les tests unitaires de politiques (pgTAP ou scripts SQL) aident, mais un test en conditions réelles depuis l'extérieur reste le meilleur révélateur des oublis.