Lovable et Supabase : la check-list RLS et sécurité avant de lancer

Une application créée avec Lovable sur Supabase met ses données dans une base PostgreSQL que le navigateur interroge directement, avec une clé publique. Ce modèle est sain à une condition : que chaque table soit protégée par des règles d'accès au niveau des lignes, les RLS (Row Level Security). Sans elles, la clé publique visible dans votre site suffit à lire, modifier ou supprimer les données. Cet article donne une check-list concrète pour vérifier votre application avant d'y faire entrer de vrais clients, chaque point renvoyant à la documentation officielle de Supabase ou de Lovable.

Il complète notre check-list sécurité d'une application codée avec l'IA, plus générale, en se concentrant sur le couple Lovable et Supabase.

Pourquoi ce sujet n'est pas théorique

En 2025, une vulnérabilité a été enregistrée sous la référence CVE-2025-48757 : des règles RLS insuffisantes dans des projets générés par Lovable permettaient à des personnes non authentifiées de lire ou d'écrire dans des tables. Lovable conteste cette référence, au motif que chaque client est responsable de la protection des données de sa propre application. Le débat sur la responsabilité importe peu à l'utilisateur dont les données ont fuité : ce qui compte, c'est de vérifier les vôtres.

La documentation de sécurité de Lovable le dit sans détour : vous êtes responsable de la conformité de votre application à vos exigences de sécurité, et ses outils ne garantissent pas une sécurité complète.

Comprendre le modèle en deux minutes

Deux familles de clés. La documentation des clés d'API de Supabase distingue :

Supabase indique que l'ancienne clé anon est en cours de dépréciation au profit de la clé publishable d'ici fin 2026. Le principe ne change pas : la clé publique est faite pour être vue, et c'est la raison pour laquelle les règles RLS ne sont pas optionnelles.

Les règles RLS. Ce sont des conditions écrites en SQL sur chaque table : « un utilisateur ne lit une facture que si elle appartient à son organisation ». Selon le guide RLS de Supabase, une fois RLS activé sur une table, aucune donnée n'est accessible par l'API avec la clé publique tant qu'aucune règle ne l'autorise. Activer sans écrire de règle bloque tout ; écrire une règle sans activer RLS ne protège rien.

La check-list

1. RLS activé sur chaque table exposée

Le guide de Supabase est explicite : activez RLS sur chaque table d'un schéma exposé. Pour lister les tables du schéma public qui n'en ont pas, lancez dans l'éditeur SQL du projet : select tablename from pg_tables where schemaname = 'public' and rowsecurity = false;

Le résultat doit être vide. Pour chaque table listée : alter table public.nom_de_la_table enable row level security; puis écrivez les règles qui conviennent. Pensez aux tables créées plus tard, au fil des demandes faites à Lovable : la vérification se refait à chaque évolution, pas une seule fois.

2. Des règles qui disent vraiment qui voit quoi

Une table avec RLS mais une règle using (true) est ouverte à tous les rôles visés : c'est l'une des erreurs que l'analyse de Lovable signale. Pour chaque table, vérifiez :

• une règle par opération : le guide Supabase recommande des règles distinctes pour la lecture, l'ajout, la modification et la suppression ;
• using et with check : la première clause décide quelles lignes existantes sont visibles ou modifiables, la seconde vérifie qu'une ligne ajoutée ou modifiée respecte la règle. Sans with check, un utilisateur peut parfois réécrire une ligne pour la rattacher à une autre organisation ;
• le rôle visé : une règle réservée aux utilisateurs connectés doit le dire (to authenticated), et le guide conseille de vérifier explicitement l'authentification plutôt que de compter sur une comparaison avec auth.uid() qui échoue en silence ;
• jamais de droits tirés des métadonnées modifiables par l'utilisateur : le guide avertit que user_metadata peut être modifié par l'utilisateur connecté lui-même. Un rôle « administrateur » stocké là n'est pas un contrôle d'accès.

Pour un SaaS, la règle type rattache chaque ligne à une organisation, et vérifie que l'utilisateur est membre de cette organisation via une table de membres. Les modèles possibles sont expliqués dans SaaS multi-tenant : ce que le fondateur doit comprendre.

Performance. Le guide recommande d'indexer chaque colonne utilisée par une règle et d'envelopper les appels de fonction comme auth.uid() dans un select, pour que le résultat soit calculé une fois par requête et non une fois par ligne. Une application qui ralentit dès quelques milliers de lignes a souvent ce problème.

3. La clé service_role ou secrète jamais côté client

Supabase est formel : ne mettez jamais une clé secrète dans un navigateur, une application distribuée ou le gestionnaire de versions. Pour vérifier :

• ouvrez votre application publiée, puis les outils de développement du navigateur, et cherchez dans les fichiers JavaScript chargés les chaînes service_role et sb_secret_ ;
• cherchez les mêmes chaînes dans le dépôt GitHub synchronisé, historique compris ;
• vérifiez que les fonctions serveur (Edge Functions) lisent leurs clés depuis les secrets du projet, pas depuis le code.

Si vous trouvez une clé secrète, considérez-la comme compromise : corrigez la cause, puis faites-la tourner, comme le recommande la documentation des clés. Supabase conseille aussi une clé secrète distincte par composant serveur, pour ne remplacer que celle qui a fuité.

4. Les buckets de stockage

Les fichiers (pièces jointes, photos, documents) vivent dans des buckets. Selon la documentation sur le contrôle d'accès du stockage :

• un bucket public est accessible à tous, sans règle : il ne doit contenir que ce qui peut être public (logos, images de présentation) ;
• un bucket privé s'ouvre par des règles RLS sur la table storage.objects ;
• par défaut, le stockage refuse les envois vers un bucket sans règle ;
• les clés secrètes contournent entièrement ces règles.

Vérifiez donc, bucket par bucket, qu'aucune facture, pièce d'identité ou document client ne se trouve dans un bucket public, et que les règles des buckets privés restreignent l'accès par utilisateur ou par organisation, par exemple en rangeant les fichiers dans un dossier au nom de l'organisation.

5. L'authentification

• Confirmation de l'adresse e-mail activée, sauf raison précise.
• Protection contre les mots de passe divulgués : Supabase la décrit dans sa page sur la sécurité des mots de passe, et Lovable y renvoie dans sa documentation.
• Adresses de redirection limitées à vos domaines, pour les liens de connexion et de réinitialisation.
• Fournisseurs de connexion inutilisés désactivés.
• Inscription ouverte ou non : un outil interne ou un SaaS sur invitation n'a pas besoin d'une inscription libre.

6. Les vues, les fonctions et les Edge Functions

Le conseiller de sécurité de Supabase signale plusieurs pièges moins visibles :

• 0013_rls_disabled_in_public (niveau erreur) : une table du schéma public sans RLS, lisible et modifiable par quiconque possède l'adresse du projet ;
• 0007_policy_exists_rls_disabled : une règle existe, mais RLS n'est pas activé, donc elle ne sert à rien ;
• 0010_security_definer_view (niveau erreur) : une vue qui s'exécute avec les droits de son créateur et ignore les règles RLS ; le correctif recommandé est security_invoker = on ;
• 0011_function_search_path_mutable : une fonction dont le chemin de recherche n'est pas fixé.

Côté Edge Functions, vérifiez que chaque fonction qui touche à des données contrôle l'utilisateur appelant, et qu'aucune n'utilise la clé secrète pour répondre à une requête sans vérifier qui la fait.

7. Le test des deux organisations

C'est le test qui ne trompe pas, et il ne demande pas d'être développeur :

1. créez deux organisations, chacune avec un administrateur et un simple utilisateur ;
2. avec chaque compte, essayez de lire, modifier et supprimer les données de l'autre organisation, y compris en changeant un identifiant dans l'adresse ;
3. déconnectez-vous et vérifiez que rien ne s'affiche ;
4. recommencez après chaque évolution qui touche une table.

Un développeur ira plus loin en interrogeant directement l'API de Supabase avec la clé publique, sans passer par l'interface, puis en automatisant ces vérifications dans des tests.

Le récapitulatif

Ce que les outils ne vérifient pas

L'analyse de Lovable et le conseiller de Supabase repèrent des erreurs connues. Ils ne savent pas qu'un comptable invité ne doit voir que deux dossiers, qu'un commercial ne voit que ses propres prospects, ou qu'une facture validée ne doit plus être modifiable. Ces règles sont votre métier : il faut les écrire, puis les tester. Si l'application traite des données personnelles, ces règles font aussi partie de vos obligations au titre du RGPD, qui impose des mesures de sécurité adaptées au risque.

Les erreurs fréquentes

• Vérifier une fois, puis continuer à demander des évolutions à Lovable. Chaque nouvelle table est une nouvelle porte.
• Corriger une alerte en élargissant la règle, par exemple en passant à using (true) pour qu'un écran « remarche ».
• Croire qu'une page masquée est une page protégée. Masquer un bouton n'empêche pas d'appeler l'API.
• Mettre de vraies données avant d'avoir fait le test des deux organisations.
• Oublier les fichiers, alors qu'ils contiennent souvent les données les plus sensibles.

Quand faire appel à un développeur

Si la check-list révèle plus de quelques corrections, si l'application accueille plusieurs entreprises clientes, ou si elle traite des données de santé, financières ou d'identité, une revue par un développeur s'impose avant l'ouverture. Notre guide mettre en production une application créée avec Lovable explique comment trier ce qui se garde, se consolide ou se réécrit. Et si vous hésitez encore sur l'outil, notre comparatif Lovable ou Claude Code aide à situer les deux approches.

LPR Studio édite et exploite ses propres logiciels, et vérifie ces mêmes points sur chacun d'eux. Si votre projet Lovable doit devenir un produit, il nous sert de point de départ : nous vous présentons en visio, sous 5 jours ouvrés, un prototype gratuit de la version de production, avant tout engagement.