RLS désactivée, la porte ouverte sur vos données
Votre app tourne, votre base répond vite. Tant mieux. Mais répond-elle uniquement aux bonnes personnes ? Sur Supabase, cette question tient en trois lettres : RLS.
La réponse en bref
La RLS, ou sécurité au niveau des lignes, décide qui peut lire ou écrire chaque enregistrement. Désactivée, une table Supabase répond à n’importe quel visiteur, même non connecté. Le test est simple : si une requête anonyme renvoie vos données, vous êtes exposé. La correction passe par des politiques d’accès au moindre privilège.
Chez Snack Groupe, cette faille revient dans presque chaque audit d’app créée par IA. Le produit fonctionne, la base est pleine, et pourtant elle répond à qui la sollicite. Rien de dramatique à condition d’agir tôt. Pour cadrer ce travail, vous pouvez découvrir Snack Développement.
La RLS, c’est quoi au juste
La RLS est une fonction de PostgreSQL, le moteur sur lequel repose Supabase. Elle filtre l’accès à chaque ligne, selon qui pose la requête. Sans elle, une table ouverte montre tout à tout le monde.
Pour comprendre le risque, il suffit de comparer les deux situations côte à côte. Ce mécanisme, hérité de PostgreSQL, change tout au niveau de la sécurité.
Pour aller plus loin sur le sujet, notre article sur pourquoi les sites IA tiennent rarement sous le trafic réel remet cette faille dans son contexte.
Pourquoi tant d’apps l’oublient
Quand un outil génère la base pour vous, l’activation de la RLS passe souvent à la trappe. Le code écrit des requêtes qui marchent, et personne ne pense à poser le filtre.
Plusieurs raisons se cumulent, presque toujours les mêmes.
Le résultat est documenté. Une analyse de DeepStrike a recensé des milliers d’instances Supabase mal configurées, et la faille CVE-2025-48757 a visé précisément ce défaut sur des applications Lovable.
Comment savoir si vous êtes exposé
Le test ne demande pas d’outil compliqué. On se met à la place d’un visiteur non connecté, puis on frappe à la porte de la base.
Supabase propose aussi un Security Advisor, un contrôle gratuit que presque personne n’utilise. Il signale les tables sans politique. En cas de doute sérieux, notre protocole d’intervention en 72 heures permet de réagir vite.
Des politiques au moindre privilège
Activer la RLS ne suffit pas. Il faut ensuite écrire des politiques qui disent, table par table, qui voit quoi. La règle d’or reste le moindre privilège : chacun accède au strict nécessaire, rien de plus.
Cette discipline rejoint le plan d’action pour sécuriser un site IA. Une bonne politique se teste, puis se réexamine à chaque nouvelle table.
Garder les clés du bon côté
Supabase fournit deux clés. La clé publique, dite clé anonyme, peut vivre côté navigateur. La clé de service, elle, ne quitte jamais la partie serveur.
Un point mérite d’être clair : la clé publique n’est un danger que si la RLS dort. Avec des politiques actives, elle devient inoffensive. Sans elle, elle ouvre la base en grand. C’est souvent là que naît la mauvaise surprise d’un sauvetage de MVP avant une levée.
Avantages et limites de la RLS
Ce que la RLS apporte
- Un filtre d’accès au plus près des données.
- Une protection même si la clé publique circule.
- Des règles lisibles, table par table.
- Une base native de PostgreSQL, sans outil ajouté.
Ses limites
- Elle se configure, elle ne s’active pas toute seule.
- Une politique mal écrite laisse encore passer trop.
- Elle ne protège pas les secrets laissés côté navigateur.
- Elle demande un test après chaque évolution.
Nos services pour verrouiller Supabase
Audit des accès
Nous testons chaque table en visiteur anonyme et listons les fuites.
Écriture des politiques
Nous posons des règles au moindre privilège, table par table.
Mise en sécurité continue
Nous assurons la maintenance et le support dans la durée.
Les développeurs échangent beaucoup sur ce point précis. La communauté Supabase sur Reddit partage de nombreux récits sur ce piège précis.
Questions fréquentes
La clé publique de Supabase est-elle dangereuse ?
Elle ne l’est que si la RLS est inactive. Avec des politiques en place sur chaque table, cette clé ne donne accès à rien de sensible.
Comment vérifier rapidement si je suis exposé ?
Déconnectez-vous, puis tentez de lire une table sensible avec la clé publique. Si la base répond, la table est ouverte. Le Security Advisor de Supabase confirme le diagnostic.
Activer la RLS suffit-il ?
Non. Une table avec RLS mais sans politique bloque tout ou laisse tout passer selon la configuration. Il faut écrire des règles précises, au moindre privilège.
La RLS ralentit-elle mon application ?
L’impact reste faible quand les politiques sont bien écrites et que les colonnes filtrées sont indexées. La sécurité gagnée dépasse largement ce coût.
Snack Groupe propose-t-il un accompagnement post-projet ?
Oui. Après la mise en sécurité, nous suivons votre base, revérifions les politiques à chaque nouvelle table et ajustons au fil de vos évolutions.
Une équipe produit dans le secteur du service en ligne nous a appelés après un doute. Leur base Supabase répondait à toute requête anonyme. En posant des politiques au moindre privilège sur chaque table, l’accès s’est refermé sans gêner les utilisateurs légitimes.
Parcours-type, service en ligne
