L'erreur de sécurité Supabase que je vois partout en ce moment
Publié le
En auditant un site généré avec Lovable, j'ai eu une surprise. En quelques minutes dans l'inspecteur de navigateur, j'avais récupéré la clé API Supabase du projet. Et en quelques requêtes, je pouvais modifier des données en base. Pas de compte administrateur. Pas de faille exotique. Juste une configuration par défaut qui n'avait jamais été revue. Cette erreur, je la vois sur de nombreux projets lancés rapidement avec des outils no-code ou des générateurs d'applications. Voici de quoi il s'agit, et surtout comment la corriger.
Ce que j'ai trouvé en auditant le site
Le site en question était fonctionnel, bien fait visuellement, généré avec Lovable et connecté à une base de données Supabase. Rien d'anormal en apparence. Puis j'ai ouvert l'onglet Réseau de l'inspecteur de navigateur et regardé les requêtes qui partaient au chargement de la page.
Dans les en-têtes de ces requêtes, deux informations étaient visibles en clair : l'URL
du projet Supabase et la clé anon. En envoyant une
requête de mise à jour avec ces informations, la réponse était un succès. Les données
avaient bien été modifiées, sans authentification, sans compte, sans aucun droit
particulier. N'importe qui visitant le site aurait pu faire la même chose.
Comprendre la clé anon : normale, mais pas anodine
Supabase fournit deux clés principales pour interagir avec votre base de données depuis
le front-end. La première est la clé anon (pour
"anonymous"), destinée à être utilisée côté client. La seconde est la clé
service_role, qui elle ne doit jamais quitter votre
serveur.
La clé anon est donc visible dans le code source de
votre application. C'est voulu, c'est documenté, et ce n'est pas un problème
en soi. Ce qui détermine ce qu'un utilisateur peut faire avec cette clé, c'est
le système de permissions que vous avez (ou non) mis en place.
Ce que la clé anon permet par défaut
Par défaut, sans configuration supplémentaire, la clé
anon donne accès en lecture et en écriture à
toutes les tables de votre base de données. Ce n'est pas un comportement caché :
Supabase prévient que sans Row Level Security activé, votre base est ouverte.
// si le RLS n'est pas activé
const { data, error } = await supabase
.from('articles')
.update({ title: 'Contenu modifié' })
.eq('id', '1');
// → 200 OK. La modification est enregistrée en base.
La faille : l'oubli du Row Level Security (RLS)
Le Row Level Security, ou RLS, est le mécanisme de Supabase qui permet de définir des
règles précises sur qui peut lire, écrire, modifier ou supprimer chaque ligne d'une
table. Sans ces règles activées, la clé anon dispose
de tous les droits sur toutes les tables.
Pourquoi cette erreur arrive-t-elle si souvent ?
Les outils de génération d'applications comme Lovable, Bolt ou d'autres créent une connexion Supabase fonctionnelle très rapidement. L'application lit et écrit des données, tout fonctionne en développement, et le site est mis en ligne. Ce que ces outils ne font pas systématiquement, c'est activer le RLS et configurer les politiques de sécurité. C'est une étape manuelle, dans le tableau de bord Supabase, que beaucoup de développeurs débutants ne connaissent pas ou oublient sous la pression du lancement.
| Sans RLS activé | Avec RLS activé |
|---|---|
La clé anon peut tout lire et tout écrire
|
La clé anon ne peut rien faire sans politique
explicite
|
| N'importe quel client HTTP peut modifier vos données | Seules les opérations explicitement autorisées sont possibles |
| Aucune distinction entre un visiteur anonyme et un utilisateur authentifié | Les règles peuvent dépendre de l'identité, du rôle ou d'une condition métier |
| Vos données sont exposées dès la mise en ligne | Vos données sont protégées par défaut, vous ouvrez ce qui doit l'être |
L'impact concret : ce qu'un visiteur peut faire
Pour être précis sur ce que cela signifie en pratique : un visiteur de votre site, sans
aucun compte ni aucune connaissance de votre code, peut ouvrir l'inspecteur de son
navigateur, récupérer votre URL Supabase et votre clé
anon, puis depuis n'importe quel client HTTP :
Un visiteur pourrait ainsi lire, créer, modifier ou supprimer des données — sans aucune authentification. Selon la nature de votre application, cela peut signifier la modification de prix sur un site e-commerce, l'altération de contenus publiés, la suppression de comptes utilisateurs ou l'accès à des informations personnelles.
Comment corriger ça : activer le RLS
La correction est simple et rapide. Elle se fait directement dans le tableau de bord Supabase, sans toucher à votre code applicatif.
Étape 1 : activer le RLS sur chaque table
Dans votre projet Supabase, rendez-vous dans Table Editor, sélectionnez
une table, puis cliquez sur l'icône de bouclier ou accédez à
Authentication → Policies. Activez le Row Level Security pour chaque
table concernée. À partir de ce moment, sans politique définie, personne ne peut accéder
à cette table via la clé anon.
Étape 2 : définir des politiques adaptées à votre usage
Une fois le RLS activé, vous devez créer explicitement les règles qui correspondent à votre logique métier. Voici quelques exemples typiques.
CREATE POLICY "Lecture publique"
ON articles
FOR SELECT
TO anon
USING (true);
-- Autoriser un utilisateur connecté à modifier uniquement ses propres données
CREATE POLICY "Modification proprietaire"
ON articles
FOR UPDATE
TO authenticated
USING (auth.uid() = user_id);
-- Bloquer toute écriture pour les utilisateurs non connectés
-- (comportement par défaut si aucune politique INSERT n'est définie)
Étape 3 : vérifier vos paramètres de stockage et d'authentification
Le RLS s'applique aux tables de votre base de données, mais pensez aussi à vérifier les politiques sur vos buckets de stockage Supabase si vous hébergez des fichiers. Le même mécanisme existe pour contrôler qui peut lire ou écrire dans un bucket.
Comment vérifier si votre projet est concerné
| Étape | Ce que vous vérifiez |
|---|---|
| Connectez-vous à votre tableau de bord Supabase | Rendez-vous dans Authentication → Policies |
| Listez toutes vos tables | Vérifiez que le RLS affiche Enabled sur chacune |
| Pour chaque table avec RLS activé | Confirmez qu'au moins une politique est définie, sinon personne ne peut y accéder |
| Tables sans RLS activé | Elles sont ouvertes en lecture et en écriture : à corriger en priorité |
Si vous utilisez Lovable, Bolt, ou tout autre outil de génération qui s'appuie sur Supabase, ce test vaut vraiment la peine d'être fait avant de partager votre lien à des utilisateurs réels.
Un mot sur les outils no-code et la responsabilité de la sécurité
Ces outils ont démocratisé la création d'applications, et c'est une très bonne chose. Mais ils créent aussi une illusion : parce que l'application fonctionne, on suppose qu'elle est correctement configurée. La sécurité ne fait pas partie des fonctionnalités visibles. Elle ne s'affiche pas dans l'aperçu, elle ne génère pas de message d'erreur tant que personne ne l'exploite.
La responsabilité de la configuration de sécurité reste celle du créateur du projet, qu'il soit développeur expérimenté ou non-développeur qui a utilisé un outil de génération. Supabase fournit les outils pour sécuriser correctement une application. Ce n'est pas parce qu'une IA a généré le code que la base de données est protégée.
Si vous avez un projet en ligne connecté à Supabase, prenez dix minutes aujourd'hui pour vérifier que le RLS est activé sur chaque table. Ce n'est pas une opération complexe. C'est juste une étape qu'on oublie facilement, et dont les conséquences peuvent être sérieuses.
