RLS Supabase désactivé : pourquoi ta base est lisible

Le RLS désactivé, c'est la faille que je trouve le plus souvent, et la plus grave. En clair : ta base de données Supabase est lisible par n'importe qui, avec la clé qui est déjà dans ton app. Pas besoin de te pirater. Il suffit de demander.

Environ 70 % des apps Lovable analysées avaient le RLS désactivé, et 1 sur 10 exposait carrément des tables en public. Voilà pourquoi ça arrive, ce que ça expose vraiment, et comment le fermer.

Le RLS, en une image

Ton app parle à ta base avec une clé publique, la clé anon (ou publishable). Cette clé est faite pour être visible, c'est normal qu'elle soit dans ton code. Elle ne verrouille rien toute seule.

Le vrai verrou, c'est le RLS, la Row Level Security. C'est lui qui décide qui a le droit de lire quelle ligne. Tant qu'il est désactivé sur une table, la clé publique suffit à tout lire. La clé sur la porte n'est pas le problème. Le problème, c'est que la porte derrière est grande ouverte.

Pourquoi autant d'apps ont le RLS désactivé

Parce que Supabase te laisse créer des tables sans RLS, et que l'IA qui a codé ton app ne l'active pas pour toi. Elle branche la base, elle fait tourner l'app, elle passe à la suite. Activer le RLS et écrire les bonnes règles, c'est un geste que personne ne fait à ta place quand tu vibe-codes.

Ce n'est pas une négligence de ta part. C'est un défaut dans la façon dont ces apps sont produites. Sauf que le résultat, lui, est bien réel.

Ce qu'un RLS désactivé expose vraiment

Tout ce qu'il y a dans les tables concernées. Les emails de tes inscrits, leurs messages, leurs commandes, leurs numéros. Un curieux ouvre les outils de développeur, repère l'appel vers ta base, rejoue la requête, et récupère les lignes. En une requête, il a une copie.

Et si ces données sont personnelles (un email en est une), tu n'as pas un bug, tu as une violation de données au sens du RGPD. La loi te demande de notifier la CNIL sous 72 heures (article 33). Une base d'emails ouverte, ce n'est pas un truc technique à corriger un jour, c'est une obligation légale dès que quelqu'un tombe dessus.

Est-ce vraiment illégal d'aller lire une base ouverte ?

Oui. Et c'est important, parce que ça explique comment on travaille chez Colmate.

Interroger la base d'un tiers, même grande ouverte, c'est accéder à un système d'information sans autorisation (article 323-1 du code pénal). Le fait que ce soit ouvert ne te protège pas : dans l'affaire Bluetouff, la personne a été condamnée alors que les documents étaient en accès libre. Bonne foi ou pas, si le propriétaire porte plainte, tu es en tort.

C'est pour ça que Colmate ne touche jamais à ta base. On déduit l'exposition probable de ce que ton app sert publiquement, on ne va pas lire tes tables pour te le prouver. On te donne la méthode pour le confirmer toi-même. On ne touche pas à tes données, et c'est un argument de confiance, pas une faiblesse.

Comment vérifier si ton RLS est activé

Le plus rapide, sans rien installer : ouvre ton app déconnecté, lance les outils de développeur de ton navigateur, onglet Réseau, et regarde si une requête vers ta base renvoie des lignes. Si oui, le RLS est désactivé sur cette table. J'ai détaillé la manip pas à pas ici.

Si tu ne veux pas passer par les DevTools, Colmate repère que ton app utilise Supabase avec une clé publique exposée côté client, le profil exact de cette faille, et te signale l'exposition probable à vérifier, avec les règles à coller. Il ne teste jamais ta base : la confirmation, c'est toi qui la fais.

Comment corriger, dans le bon ordre

Deux étapes. D'abord tu actives le RLS sur la table, ensuite tu ajoutes une règle qui dit qui a le droit de lire. Activer le RLS sans règle bloque tout, y compris ton app, donc on pose la règle dans la foulée.

Exemple pour une table dont chaque ligne appartient à un utilisateur :

ALTER TABLE public.ma_table ENABLE ROW LEVEL SECURITY;

CREATE POLICY "lecture_par_proprietaire" ON public.ma_table
  FOR SELECT USING (auth.uid() = user_id);

Et surtout : ne mets jamais la clé service_role côté client pour contourner le problème. Ça revient à retirer complètement le verrou.

FAQ

Le RLS désactivé, c'est grave même si mon app est petite ?

Oui. La taille de ton app ne change rien au fait que la base est lisible. Une petite app avec 200 emails ouverts, c'est 200 personnes dont tu es responsable au sens du RGPD. Et une fuite qui se sait coûte souvent plus cher en confiance qu'en amende.

Ma clé anon Supabase est visible, dois-je la cacher ?

Non, la clé anon est publique par design, elle est censée être dans ton app. La cacher ne sert à rien et n'est pas le sujet. Ce qui compte, c'est que le RLS soit activé derrière. Une clé anon visible plus un RLS activé, c'est une app saine.

Activer le RLS va-t-il casser mon app ?

Ça peut, si tu actives le RLS sans poser de règle : plus personne ne lit la table, ton app comprise. C'est pour ça qu'on active et qu'on ajoute la policy dans le même mouvement. Teste après chaque table sur un compte réel pour vérifier que tout fonctionne encore.

Si tu ne vérifies qu'une chose

Le RLS, c'est le point le plus grave et le plus courant. Si tu ne dois en vérifier qu'un avant de lancer, c'est celui-là. Lance un scan gratuit, ou repars de la checklist complète avant déploiement.