Supabase RLS expliqué simplement, avec exemples

La RLS (Row Level Security, sécurité au niveau des lignes) est un filtre que la base de données applique à chaque requête : elle ne renvoie et ne modifie que les lignes qu'un utilisateur a le droit de toucher. Dans Supabase, c'est elle qui protège vos données, car la clé utilisée par l'interface est publique.

Le principe en une image

L'interface demande « tous les dossiers ». La base répond « voici les dossiers que cet utilisateur a le droit de voir ». Le filtrage se fait dans la base, pas dans l'écran : même une personne qui contournerait votre application se heurterait au même filtre.

Trois règles de base :

• Une table avec la RLS désactivée est lisible par quiconque possède la clé publique.
• Une table avec la RLS activée mais sans aucune règle est fermée à tous.
• Une opération sans règle (par exemple la suppression) est refusée à tous.

USING et WITH CHECK

Une règle s'écrit pour une opération : lecture, création, modification ou suppression. Elle utilise deux clauses :

• USING décide quelles lignes existantes sont visibles ou modifiables. C'est la porte d'entrée.
• WITH CHECK décide si la nouvelle version d'une ligne est acceptable, à la création ou après une modification. C'est la porte de sortie.

Trois exemples

Lecture de ses propres lignes :

create policy "notes_select_own" on public.notes
  for select to authenticated
  using (user_id = auth.uid());

Création limitée à soi-même :

create policy "notes_insert_own" on public.notes
  for insert to authenticated
  with check (user_id = auth.uid());

Modification par un collaborateur attribué au client, sans pouvoir déplacer la ligne vers un autre client :

create policy "dossiers_update_assigned" on public.dossiers
  for update to authenticated
  using (private.is_assigned(client_id))
  with check (private.is_assigned(client_id));

Sans la clause WITH CHECK, ce collaborateur pourrait modifier un dossier qu'il voit et changer son client pour le rattacher à un client qu'il ne suit pas.

Les pièges fréquents

1. La condition toujours vraie. Autoriser la lecture à tout utilisateur connecté protège des visiteurs anonymes, mais tous vos clients voient tout.
2. Les règles qui tournent en rond. Une règle sur la table des rôles qui lit la table des rôles provoque une récursion. Passez par une fonction dédiée, en security definer, placée dans un schéma non exposé par l'API.
3. Les tables de liaison oubliées. Une table d'attributions lisible par tous révèle qui suit quel client.
4. Le rôle dans le profil. Si l'utilisateur peut modifier son profil et que son rôle y figure, il peut se déclarer administrateur. Rangez les rôles dans une table séparée.
5. L'erreur silencieuse. Une modification refusée par une règle ne renvoie souvent aucune erreur : zéro ligne modifiée. Vérifiez le nombre de lignes touchées dans l'application et affichez un message.

Demander les règles à Lovable

Vous n'avez pas à écrire ce SQL vous-même. Décrivez vos droits à Lovable, en mode Plan, sous forme de tableau : pour chaque rôle, ce qu'il peut lire, créer, modifier et supprimer. Demandez une migration qui active la RLS et crée une règle par opération, avec WITH CHECK pour les créations et modifications, puis relisez le plan avec trois questions :

• Chaque table a-t-elle la RLS activée dans la migration ?
• Les règles correspondent-elles exactement à votre tableau des droits ?
• Les opérations interdites (souvent la suppression) sont-elles bien absentes ?

Pour les vérifications de rôle, demandez une fonction dédiée placée dans un schéma privé, par exemple une fonction qui répond oui ou non à la question « l'utilisateur connecté est-il administrateur ? ». Le conseiller de sécurité de Supabase signale une telle fonction si elle reste appelable directement par l'API.

Tester ses règles

Une règle non testée n'est pas une règle. Construisez une matrice : en lignes, chaque table et chaque opération ; en colonnes, chaque profil de test (client A, client B, collaborateur attribué, collaborateur non attribué, administrateur, visiteur anonyme). Indiquez le résultat attendu, puis testez :

• dans l'application, y compris en recopiant l'adresse d'une page qui ne vous appartient pas ;
• dans l'éditeur SQL de Supabase, en exécutant les requêtes avec l'identité d'un utilisateur de test ;
• avec le conseiller de sécurité de Supabase, après chaque migration.

Pensez aussi à indexer les colonnes utilisées dans vos règles, comme l'identifiant du client : sur de grandes tables, une règle non indexée ralentit chaque requête.

Questions fréquentes

Faut-il activer la RLS sur toutes les tables ?

Oui, sur toutes les tables accessibles par l'API, y compris les tables techniques et de liaison.

La RLS ralentit-elle l'application ?

Très peu si les colonnes utilisées dans les règles sont indexées.

Que faire si une liste reste vide après l'activation de la RLS ?

C'est souvent le signe qu'une règle manque ou qu'une donnée de liaison est absente, par exemple une attribution. Ne désactivez jamais la RLS pour faire réapparaître les données : identifiez la règle ou la donnée en cause.

Peut-on tester la RLS sans savoir écrire de SQL ?

Oui, en grande partie, en testant l'application avec plusieurs comptes. L'éditeur SQL permet ensuite d'aller plus vite.

Sources : documentation de Supabase (sécurité au niveau des lignes, conseiller de sécurité), consultée le 20.10.2026.