Lovable et Supabase : la faille RLS que tu dois fermer

Lovable et Supabase, c'est le combo par défaut de la plupart des apps que je scanne. Lovable décrit ta base à Supabase, crée les tables, branche la clé publique, et ton app tourne. Le geste qui manque presque toujours dans ce combo, c'est celui qui verrouille la base : activer le RLS et écrire les règles.

Résultat concret : environ 70 % des apps Lovable analysées ont le RLS désactivé, et 1 sur 10 expose carrément des tables en public. Ta clé publique suffit alors à lire toute ta base. Voici pourquoi ça arrive spécifiquement sur Lovable, comment le voir, et les règles exactes à coller pour fermer la porte.

Pourquoi le combo Lovable + Supabase laisse le RLS ouvert

Supabase te laisse créer des tables sans RLS. C'est un choix de leur part : la table existe, elle est utilisable, et c'est à toi d'activer le verrou. Lovable, de son côté, optimise pour que ton app marche. Quand l'IA génère une fonctionnalité, elle crée la table, elle branche la clé anon, elle fait tourner l'app. Activer le RLS et poser les bonnes policies, c'est un geste séparé que rien ne déclenche automatiquement dans ce flux.

Ce n'est pas une négligence de ta part. C'est un trou dans la façon dont ces deux outils s'emboîtent : chacun suppose que l'autre, ou toi, va poser le verrou. Personne ne le fait, et l'app part en prod avec la base ouverte. Le fond de cette faille, au-delà de Lovable, est expliqué dans RLS désactivé : pourquoi ta base est lisible.

La clé publique n'est pas le problème

Il faut lever un malentendu qui revient tout le temps. La clé anon de Supabase (parfois appelée publishable) est faite pour être publique. Elle est dans ton code Lovable, elle est visible dans le navigateur, et c'est normal. La cacher ne sert à rien.

Cette clé ne verrouille rien toute seule. Le vrai verrou, c'est le RLS (Row Level Security), qui décide, ligne par ligne, qui a le droit de lire quoi. La clé sur la porte n'est pas le souci. Le souci, c'est que la porte derrière est restée grande ouverte. Une clé anon visible plus un RLS activé, c'est une app saine. Une clé anon visible plus un RLS désactivé, c'est ta base lisible par le premier venu.

Comment voir si ton RLS Lovable est désactivé

Deux façons, sans rien casser.

Depuis ton app, en deux minutes : ouvre-la déconnecté, lance les DevTools de ton navigateur, onglet Réseau, filtre sur supabase. Clique sur une requête qui contient rest/v1/ suivi d'un nom de table, ouvre la Réponse. Si tu vois des lignes de données, le RLS est désactivé sur cette table. J'ai détaillé la manip pas à pas dans vérifier si ta base Supabase est ouverte.

Depuis Supabase directement : dans le tableau de bord, ouvre l'onglet Table Editor. Les tables sans le cadenas RLS activé sont signalées. Tu peux aussi ouvrir l'Authentication puis Policies pour voir lesquelles ont des règles et lesquelles n'en ont aucune.

Colmate, lui, ne va jamais interroger ta base pour trancher. Il repère que ton app Lovable 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. C'est toi qui confirmes, avec l'une des deux méthodes ci-dessus. On ne touche pas à tes données, et c'est un argument de confiance.

Les règles à coller pour fermer la porte

La correction se fait en deux temps, et l'ordre compte. D'abord tu actives le RLS sur la table. Ensuite tu ajoutes une policy qui dit qui a le droit de lire. Si tu actives le RLS sans policy, plus personne ne lit la table, ton app comprise. On pose donc les deux dans la foulée.

Tu peux coller ce SQL dans l'éditeur SQL de Supabase, ou demander à Lovable de l'appliquer. Exemple pour une table dont chaque ligne appartient à un utilisateur (une table de commandes, de messages, de profils) :

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);

CREATE POLICY "ecriture_par_proprietaire" ON public.ma_table
  FOR INSERT WITH CHECK (auth.uid() = user_id);

Pour une table volontairement publique en lecture (un catalogue, des articles de blog), mais que tu veux protéger en écriture :

ALTER TABLE public.contenu_public ENABLE ROW LEVEL SECURITY;

CREATE POLICY "lecture_pour_tous" ON public.contenu_public
  FOR SELECT USING (true);

Fais-le table par table, en testant ton app sur un compte réel après chaque table pour vérifier que tout fonctionne encore. Et ne mets jamais la clé service_role côté client pour contourner le problème : ça revient à retirer complètement le verrou.

L'erreur à ne surtout pas faire pour « aller plus vite »

Quand le RLS bloque une requête et que l'app casse, la tentation est de sortir la clé service_role et de l'utiliser depuis le front pour que ça repasse. C'est la pire idée possible. La service_role ignore le RLS et donne un accès complet, en lecture et en écriture, à toute ta base. La poser dans le navigateur, c'est laisser la clé de ta maison sur le paillasson avec un panneau bienvenue.

La bonne façon, c'est de garder la service_role côté serveur uniquement, dans une Edge Function Supabase, et d'écrire des policies correctes pour ce que le front doit lire. C'est un peu plus de travail sur le moment. C'est la différence entre une base fermée et une base ouverte.

La version rapide

Si tu veux juste savoir où tu en es avant de lancer, Colmate scanne ton app Lovable en trente secondes et te signale si le profil de cette faille est présent (Supabase branché, clé publique exposée), avec les points à vérifier et le correctif prêt à coller. En lecture seule, sans accéder à ton code, sans jamais toucher à ta base.

Scanne ton app Lovable maintenant, puis reviens fermer les tables une par une avec le SQL ci-dessus.

FAQ

Lovable active-t-il le RLS Supabase tout seul ?

Pas de façon fiable. Lovable crée les tables et branche la clé publique, mais l'activation du RLS et l'écriture des policies ne sont pas automatiques dans ce flux. C'est pour ça que la majorité des apps Lovable que je scanne ont le RLS désactivé sur au moins une table. À vérifier avant chaque lancement.

Est-ce que je dois cacher ma clé anon Supabase dans Lovable ?

Non. La clé anon est publique par design, elle est censée être dans ton app pour parler à la base. La cacher ne protège rien et n'est pas le sujet. Ce qui protège ta base, c'est le RLS activé derrière. Concentre-toi là-dessus, pas sur la clé publique.

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

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

Si tu ne fermes qu'une chose avant de lancer

C'est le RLS. Sur le combo Lovable + Supabase, c'est le point le plus grave et le plus courant. Lance un scan gratuit pour voir si le profil est présent, repars de la checklist complète avant déploiement, ou reprends la checklist Lovable point par point.