Supabase RLS : sécuriser ses tables, guide pour débutants

RLS Supabase : c’est quoi et pourquoi l’activer

La RLS (Row Level Security) désigne une fonction de Postgres qui filtre, pour chaque table, les lignes qu’un utilisateur peut lire ou modifier, grâce à des règles SQL appelées politiques. Sur Supabase, une table exposée sans RLS est lisible et modifiable par tout rôle qui a les droits dessus.

La documentation de Supabase le dit clairement : les tables et vues exposées par la Data API sans RLS sont accessibles à tout rôle disposant des droits correspondants source : Supabase Docs, 2026. Le navigateur de ton application appelle directement la base, avec une clé publique visible dans le code de la page. Cette clé n’est pas un secret. Seule la RLS décide de ce qu’elle permet.

C’est ce qui s’est passé avec la CVE-2025-48757 : une politique RLS insuffisante dans Lovable, jusqu’au 15 avril 2025, permettait à des attaquants non authentifiés de lire ou d’écrire dans des tables arbitraires des sites générés source : GitHub Advisory Database, 2025. Ce n’est pas un bug de Supabase, c’est une configuration manquante dans les projets générés. Le cas complet est raconté dans notre article sur les risques du vibe coding.

Ce guide s’adresse à toi si ton application a été construite avec Lovable, Claude Code ou Codex, et que tu n’as jamais vérifié ce point.

Prérequis

Un projet Supabase avec au moins une table contenant des données d’utilisateurs.
Un accès au Dashboard du projet.
Une colonne user_id dans chaque table concernée, qui stocke l’identifiant de l’utilisateur propriétaire de la ligne.
Deux comptes de test dans ton application (A et B).

Étape 1 : vérifier la RLS table par table

Ouvre Database puis Policies dans le Dashboard. Chaque table y est listée avec ses politiques. Une table sans politique et sans RLS est ta première priorité.

Les tables créées depuis le Dashboard ont la RLS activée par défaut. Celles créées dans le SQL Editor ou par un autre outil doivent l’avoir activée explicitement source : Supabase Docs, 2026. Une table créée par une migration générée par l’IA entre dans la seconde catégorie.

Pour lister les politiques existantes d’une table, lance dans le SQL Editor :

select * from pg_policies where tablename = 'todos';

Aucun résultat signifie aucune politique. Remplace todos par le nom de ta table.

Étape 2 : activer la RLS

Dans Database puis Policies, clique sur le bouton Enable RLS de la table. Tu peux aussi le faire en SQL :

alter table todos enable row level security;

Une fois la RLS activée, plus aucune ligne n’est accessible par l’API avec la clé publishable tant qu’aucune politique ne l’autorise source : Supabase Docs, 2026. Ton application affichera donc des listes vides juste après. C’est normal, et c’est l’étape suivante qui règle le problème.

La commande grant contrôle l’accès du rôle à la table, tandis que la RLS et les politiques contrôlent l’accès aux lignes. La documentation recommande de regrouper les deux dans la même migration source : Supabase Docs, 2026. Ce point devient obligatoire : depuis le 30 mai 2026 pour les nouveaux projets, et à partir du 30 octobre 2026 pour tous les projets, Supabase n’expose plus automatiquement les nouvelles tables du schéma public à la Data API, et un grant explicite est nécessaire en plus de la RLS source : Supabase Changelog, 28 avril 2026.

Étape 3 : écrire une règle « chaque utilisateur voit ses lignes »

Une politique (policy) est une règle SQL attachée à une table qui autorise une opération précise (lire, insérer, modifier, supprimer) pour certaines lignes. Elle agit comme un filtre ajouté implicitement à chaque requête source : Supabase Docs, 2026.

Voici une politique de lecture, adaptée de l’exemple officiel :

create policy "Individuals can view their own todos."
on todos for select
to authenticated
using ( (select auth.uid()) = user_id );

Trois détails comptent, tous issus des bonnes pratiques de la documentation :

to authenticated limite la règle aux utilisateurs connectés.
(select auth.uid()) s’écrit avec le select autour, plutôt que auth.uid() seul.
La colonne user_id mérite un index, car elle sert à chaque requête.

Écris ensuite une politique par opération :

Opération	Clause à utiliser	Rôle de la clause
select	`using`	Filtre les lignes visibles
insert	`with check`	Vérifie la ligne créée
update	`using` et `with check`	Vérifie la ligne existante, puis la ligne résultante
delete	`using`	Filtre les lignes supprimables

Pour l’update, using contrôle la ligne avant modification et with check la ligne après. Sans with check, using décide aussi des nouvelles valeurs autorisées, et un update ne fonctionne que si une politique select couvre aussi la ligne source : Supabase Docs, 2026.

Étape 4 : tester avec deux comptes

Un test à deux comptes est un conseil de la communauté, pas une procédure officielle de Supabase. Il reste le plus fiable pour un débutant, car il reproduit ce qu’un vrai utilisateur peut tenter source : DEV Community, 2026.

Connecte-toi dans l’application avec le compte A et crée une ligne.
Déconnecte-toi, puis connecte-toi avec le compte B.
Vérifie que B ne voit pas la ligne de A.
Essaie de modifier ou de supprimer la ligne de A depuis B : rien ne doit changer.
Déconnecte-toi complètement et recharge la page : un visiteur anonyme ne doit rien voir.

Si l’un de ces points échoue, une politique est trop large ou manque.

Étape 5 : contrôler les clés utilisées

Le vocabulaire a changé. La clé publishable (sb_publishable_…) est la clé publique qui remplace la clé historique anon, et la clé secret (sb_secret_…) remplace service_role. Supabase annonce la dépréciation des clés anon et service_role d’ici fin 2026 source : Supabase Docs, 2026.

Un tutoriel qui te demande de copier une longue clé commençant par eyJ a été écrit pour les clés legacy. Les anciennes clés restent actives tant que tu ne les désactives pas dans Settings puis API Keys source : Supabase Docs, 2026.

La clé secret contourne la RLS : le rôle service_role a l’attribut BYPASSRLS, donc aucune politique ne s’applique à elle. Elle ne doit jamais apparaître dans du code côté navigateur. Si tu as un doute, suis la démarche de clé API exposée dans le code.

Pièges courants

Symptôme	Cause	Solution
Les données ont disparu après l’activation	Aucune politique n’existe, l’API ne renvoie rien	Écris les politiques de l’étape 3, ne désactive pas la RLS
Les requêtes reviennent vides malgré une politique	Utilisateur non connecté, ou `user_id` vide dans les lignes	Vérifie la connexion et le contenu de la colonne
Tout le monde voit tout	Politique écrite avec `using (true)`	Remplace par une condition sur `user_id`
Les nouvelles lignes n’appartiennent à personne	`user_id` non renseigné à l’insertion	Définis `default auth.uid()` sur la colonne ou envoie-le depuis l’application

Une politique using (true) revient à ne pas avoir de RLS pour les rôles visés. L’IA en génère parfois pour « faire marcher » l’application : relis chaque politique avant de la garder.

Autre réflexe à éviter : désactiver la RLS pour faire réapparaître les données. Cela règle l’affichage et rouvre la base à tout le monde.

Si ton projet est déjà en production, applique la même rigueur qu’à la reprise d’un site existant : liste les tables, vérifie chacune.

Comment activer la RLS sur Supabase ?

Dans le Dashboard, ouvre Database puis Policies et clique sur Enable RLS sur la table. En SQL, lance alter table nom_de_la_table enable row level security;, puis écris au moins une politique.

Pourquoi mes données ne s'affichent plus après l'activation de la RLS ?

Parce qu’aucune politique n’autorise la lecture : avec la clé publishable, l’API ne renvoie aucune ligne par défaut. Écris une politique select pour le rôle authenticated, comme à l’étape 3.

La clé publishable est-elle dangereuse si elle est visible dans mon code ?

Non, le changelog de Supabase la décrit comme une clé de faible privilège qui peut être exposée en ligne. Elle ne protège rien seule : la sécurité repose sur la RLS de chaque table.

Avant de mettre quoi que ce soit en ligne, ouvre Database puis Policies et passe tes tables une par une. Une table sans RLS et sans politique est un défaut à corriger le jour même.

Contactez Peechy et vous n'aurez pas ce bug

Vous construisez un site ou une application avec l'IA ? On relit le code, on teste ce qui ne se voit pas à l'écran, accès, données, options de confidentialité, et on corrige avant la mise en ligne.

Contacter Peechy