Application Lovable : comment vérifier la sécurité Supabase (RLS)

Votre application a été construite avec Lovable, ou avec un autre outil de vibe coding qui s'appuie sur Supabase ? Alors sa sécurité Supabase repose presque entièrement sur un réglage : le RLS, pour Row Level Security. Ce sont les règles qui décident quelle ligne de la base de données chaque utilisateur a le droit de lire ou de modifier. Sans ces règles, ou avec des règles mal écrites, n'importe qui peut lire vos données sans même se connecter.

Ce n'est pas une menace théorique. En 2025, un chercheur a analysé 1 645 applications publiées avec Lovable. Dans 170 d'entre elles, les données étaient accessibles de cette façon. La faille a reçu un identifiant officiel : CVE-2025-48757.

Bonne nouvelle : vérifier le RLS de votre application est un travail limité. Voici pourquoi c'est là que tout se joue, comment le contrôler, et les pièges qui restent même quand le RLS est « activé ».

Pourquoi la sécurité d'une application Lovable se joue dans Supabase

Dans une application classique, le navigateur de l'utilisateur parle à un serveur. C'est ce serveur qui interroge la base de données, en vérifiant les droits au passage. Une application Lovable branchée sur Supabase fonctionne autrement : le navigateur interroge directement la base de données, par l'interface que fournit Supabase.

Pour cela, le code de votre application contient une clé publique, souvent appelée anon key. N'importe qui peut la voir en ouvrant les outils de développement de son navigateur. C'est normal et prévu : cette clé n'est pas un secret. Ce qui protège vos données, ce ne sont pas les écrans de votre application, c'est le RLS.

La documentation de Supabase le dit clairement : une table exposée sans RLS peut être lue et modifiée par tous ceux qui y ont accès. Il faut donc activer le RLS sur chaque table exposée. Autrement dit, si une table de clients n'a pas de règles, la cacher dans l'interface ne sert à rien. Quelqu'un qui connaît la clé publique peut l'interroger directement.

Ce qui s'est passé avec la faille CVE-2025-48757

Le chercheur Matt Palmer a publié le détail de sa découverte. Voici les faits principaux :

• le 20 mars 2025, il constate qu'une application construite avec Lovable laisse lire ses tables sans authentification ;
• le 21 mars, il prévient Lovable et termine l'analyse de 1 645 applications : 170 projets, soit environ 10,3 %, ont le même défaut, sur 303 points d'accès au total ;
• parmi les données accessibles figuraient des adresses e-mail, des numéros de téléphone, des adresses postales, des informations de paiement et d'abonnement, ainsi que des clés d'accès à des services tiers ;
• la faille est publiée officiellement le 29 mai 2025 sous l'identifiant CVE-2025-48757.

Un détail vous concerne directement. Selon le chercheur, le scanner de sécurité ajouté par Lovable en avril 2025 vérifiait que des règles RLS existaient. Il ne vérifiait pas qu'elles étaient correctes, ni qu'elles correspondaient à la logique de l'application. Une case « RLS activé » cochée ne garantit donc pas que vos données sont protégées.

Le problème dépasse Lovable. Le rapport 2025 de Veracode a testé plus de 100 modèles d'IA : le code qu'ils ont produit contenait des failles de sécurité dans 45 % des tests. Ces outils produisent une application qui fonctionne. Ils ne garantissent pas une application sûre.

Vérifier le RLS Supabase de votre application en 5 points

Pour cette vérification, il faut un accès au tableau de bord Supabase de votre projet. Si vous n'êtes pas à l'aise, faites-la avec quelqu'un de technique, mais gardez la liste en main : vous saurez ainsi ce qui a été contrôlé.

1. Lister toutes les tables et vérifier que le RLS est activé sur chacune. Le tableau de bord Supabase signale les tables sans RLS, et son outil de conseils de sécurité (Security Advisor) les liste aussi. Une seule table oubliée suffit, y compris une table « technique » créée par l'IA en cours de route.
2. Relire chaque règle. Pour chaque table, une règle dit qui a le droit (visiteur anonyme ou utilisateur connecté), pour quelle opération (lire, créer, modifier, supprimer) et à quelle condition. Méfiez-vous des conditions toujours vraies. La documentation Supabase rappelle qu'une règle de lecture to anon using (true) laisse tout visiteur non connecté lire toutes les lignes.
3. Tester comme un inconnu. Créez deux comptes de test, A et B. Connecté avec le compte A, essayez de voir ou de modifier les données de B. Puis recommencez sans être connecté. C'est ce test qui compte : il vérifie ce qui se passe vraiment, pas ce qui était prévu.
4. Chercher la clé secrète. Supabase fournit aussi une clé secrète, liée au rôle service_role, qui passe outre toutes les règles RLS. Sa documentation est claire : elle ne doit jamais être utilisée dans le navigateur ni montrée aux clients. Vérifiez qu'elle n'apparaît nulle part dans le code qui tourne dans le navigateur, ni dans un dépôt de code public.
5. Ne pas oublier les fichiers. Votre application stocke peut-être des documents : factures, pièces d'identité, photos. Le stockage de fichiers de Supabase a lui aussi ses règles d'accès. Faites-lui passer le même test avec deux comptes.

Les erreurs fréquentes, même quand le RLS est activé

Activer le RLS partout n'est qu'un point de départ. Les problèmes qu'on rencontre ensuite viennent de règles qui existent, mais qui ne disent pas ce que vous croyez :

• Une règle trop large pour les utilisateurs connectés. Si n'importe qui peut s'inscrire, « tout utilisateur connecté peut lire la table » revient à « tout le monde peut lire la table ».
• Un utilisateur qui peut modifier toute sa propre ligne. Imaginons une table des profils avec une colonne qui indique le rôle ou l'abonnement, et une règle qui autorise chacun à modifier son profil. Rien n'empêche alors quelqu'un de se donner lui-même le statut d'administrateur ou l'abonnement premium.
• Des contrôles faits seulement dans l'interface. Un prix calculé dans le navigateur, une limite d'usage assurée par un bouton grisé : comme la base de données peut être interrogée directement, tout contrôle qui n'existe que dans l'interface peut être contourné.
• Une règle élargie pour « débloquer » une fonctionnalité. Quand une requête est refusée, la correction la plus rapide consiste à assouplir la règle. Si vous avez demandé à l'IA de « réparer » un écran qui ne chargeait pas, vérifiez ce qu'elle a changé dans la base.
• Les vues SQL. Une vue est une requête enregistrée dans la base. Selon la façon dont elle a été créée, elle peut s'exécuter avec les droits de la personne qui l'a créée, et donc ignorer le RLS des tables qu'elle lit. Chaque vue exposée doit être vérifiée.

Après la vérification : garder le contrôle dans la durée

Une vérification ponctuelle protège l'application telle qu'elle est aujourd'hui. Mais une application construite par vibe coding change vite : chaque nouvelle fonctionnalité peut ajouter une table, une règle ou une vue. Le risque revient donc à chaque évolution.

Trois habitudes suffisent à garder le contrôle :

• refaire le test des deux comptes après chaque fonctionnalité qui touche aux données ;
• faire relire par une personne technique toute modification des règles RLS, même petite ;
• tenir une liste simple des tables qui contiennent des données personnelles ou financières, pour savoir où regarder en premier.

C'est exactement le rôle de l'offre Copilote : une journée de développeur senior par mois pour relire ce qui a changé, tester les accès et vous dire clairement ce qui pose problème. Pendant ce temps, vous continuez à faire évoluer l'application vous-même. Si vous préparez une première mise en ligne, l'article Mettre en production une application vibe coding : ce qu'il faut vérifier avant complète cette liste avec les autres points à contrôler.

Questions fréquentes

La clé Supabase visible dans le code de mon application, est-ce grave ?

Pas si c'est la clé publique (anon) et que le RLS est bien configuré : elle est faite pour être visible. C'est grave si c'est la clé secrète (service_role), qui passe outre toutes les règles. Dans ce cas, remplacez-la sans attendre depuis le tableau de bord Supabase.

Le scanner de sécurité intégré à Lovable suffit-il ?

C'est une première alerte utile, pas une validation. D'après le chercheur qui a découvert la faille CVE-2025-48757, ce scanner vérifiait que des règles existaient, pas qu'elles étaient justes. Seul un vrai test avec plusieurs comptes vous dit qui voit quoi.

Faut-il tout réécrire si les règles sont mauvaises ?

Rarement. Dans la plupart des cas, on corrige les règles table par table, sans toucher à l'interface. Une réécriture ne se discute que si toute la logique métier importante se trouve dans le navigateur.

Si vous avez un doute sur la façon dont votre application protège les données de vos clients, parlons-en. Une première lecture des règles et un test avec deux comptes donnent déjà une réponse claire : vous saurez s'il y a urgence ou seulement quelques réglages à faire.