En mai 2025, un chercheur en sécurité scanne 1 645 applications mises en avant par Lovable sur sa propre vitrine. Résultat : 170 d'entre elles — 10,3 % — laissent fuiter des données. Noms, emails, numéros de téléphone, adresses postales, et même des montants de dettes personnelles. Le tout accessible sans le moindre identifiant. La faille a un nom : CVE-2025-48757.
Si vous avez construit une app sur Lovable et qu'elle stocke des données réelles, cet article vous concerne directement. On explique ce qui se passe, pourquoi c'est structurel, et comment vérifier — en lecture seule — si votre application est exposée.
Ce qu'est la faille CVE-2025-48757, sans jargon
Lovable génère des applications dont le backend repose sur Supabase. Supabase, c'est une base de données PostgreSQL exposée directement à votre application front-end via une API REST. Pour que ce soit sécurisé, une seule chose protège vos tables : le RLS (Row Level Security), un ensemble de règles qui décident qui a le droit de lire ou écrire quelle ligne.
Le problème : sans RLS correctement configuré, toutes les tables sont lisibles par tout le monde. Et la clé qui permet d'interroger l'API — la "clé anon" — est par conception publique : elle est embarquée dans le code JavaScript de votre page, visible par n'importe qui en deux clics dans les outils de développement du navigateur.
Concrètement, l'attaque ne demande aucune compétence avancée :
- Ouvrir votre app, récupérer l'URL Supabase et la clé anon dans le bundle (elles sont en clair).
- Appeler directement l'API REST :
GET /rest/v1/users?select=*. - Si le RLS est absent ou mal écrit, la base renvoie toute la table — liste des utilisateurs, paiements, messages, peu importe.
C'est exactement ce qui a été démontré publiquement. Le 14 avril 2025, un ingénieur de Palantir a publié des exemples d'extraction de montants de dettes, d'adresses personnelles et de clés API depuis des apps Lovable en production.
Pourquoi ce n'est pas un bug isolé mais un problème structurel
On pourrait croire que ces 170 apps sont des cas négligents. La réalité est plus gênante.
Le RLS n'est pas activé par défaut de façon utile. Générer une app fonctionnelle et générer une app sécurisée sont deux choses différentes. L'IA produit quelque chose qui marche — l'écran s'affiche, les données apparaissent. Que ces mêmes données soient aussi accessibles sans authentification ne se voit pas à l'usage. Tout va bien jusqu'au jour où quelqu'un regarde.
Le "security scan" de Lovable ne suffit pas. En avril 2025, Lovable a sorti une version 2.0 avec un scanner de sécurité. Mais ce scanner vérifie la présence de politiques RLS, pas si elles fonctionnent. Une politique mal écrite passe le test et laisse quand même fuiter les données. C'est une fausse assurance.
Et ce n'est pas la seule faille. En mars 2026, une seconde vulnérabilité a été divulguée : une faille d'autorisation (BOLA) permettant, avec un simple compte gratuit et quelques appels API, d'accéder au code source, aux identifiants de base de données et aux historiques de conversation d'autres projets — tous ceux créés avant novembre 2025. Signalée via HackerOne, elle est restée sans correctif pour les anciens projets au moment de la divulgation.
Plus largement, une étude de Stanford estime que 45 % du code généré par IA contient des vulnérabilités. Le générateur optimise pour "ça marche", pas pour "c'est sûr".
Est-ce que ça veut dire que Lovable est à bannir ? Non.
Soyons honnêtes : chez Flowlab, on utilise Lovable. Pour des sites vitrines, des landing pages, des prototypes cliquables qu'on jette ensuite, c'est excellent et on le recommande. La vitesse est réelle.
La ligne, c'est le moment où l'application porte des données réelles : clients, facturation, accès, informations personnelles. À ce moment-là, un proto généré n'est plus un proto — c'est un système de production qui engage votre responsabilité (et le RGPD). Et le RLS par défaut ne suffit pas à le protéger.
Ce n'est pas un problème de Lovable contre le reste. C'est un problème de prototype utilisé comme produit.
Comment savoir si votre app est exposée
Bonne nouvelle : on peut vérifier la partie la plus dangereuse — la surface accessible sans authentification — en lecture seule, sans rien casser, exactement comme le ferait n'importe quel visiteur de votre site.
La méthode :
- Récupérer l'URL Supabase et la clé anon de votre app (elles sont publiques, dans le code de la page).
- Interroger l'API REST table par table avec cette clé, sans être authentifié.
- Constater quelles tables renvoient des données. Toute table qui répond avec des lignes sans login est exposée.
C'est précisément ce que fait notre audit de sécurité Lovable / Supabase : vous donnez l'URL de votre app, on lance nos outils dessus, et on vous renvoie un rapport clair le jour même. Checks strictement en lecture seule, non destructifs, on ne stocke jamais les données exposées — seulement le constat. Un pré-scan instantané est aussi disponible directement dans votre navigateur.
Que faire si votre app fuit
Si l'audit révèle des tables exposées, par ordre de priorité :
1. Activer un RLS réellement restrictif sur chaque table — pas une politique vide qui "existe" mais ne filtre rien. Chaque table doit n'autoriser que les lignes que l'utilisateur authentifié a le droit de voir.
2. Vérifier les fonctions et RPC — les fonctions SECURITY DEFINER avec un search_path mutable sont une porte dérobée classique. Les endpoints exécutables en anon doivent être verrouillés.
3. Faire tourner la clé (rotation) si une exposition a eu lieu — si vos données ont pu fuir, considérez la clé et les identifiants comme compromis, et changez-les.
4. Décider : corriger ou reprendre — si la base est saine, on sécurise. Si la dette est telle que corriger coûte plus cher que reconstruire proprement, on le dit franchement. C'est l'objet du diagnostic.
FAQ — sécurité des apps Lovable
La clé anon dans mon code, c'est normal ?
Oui — la clé anon est publique par conception, elle est faite pour être dans le navigateur. Ce n'est pas elle le problème. Le problème, c'est ce qu'elle permet de lire quand le RLS ne fait pas son travail. Avec un bon RLS, la clé anon ne donne accès à rien de sensible.
Mon app n'est pas dans la vitrine Lovable, suis-je concerné ?
Potentiellement, oui. Les 10,3 % concernent les apps de la vitrine, mais la cause — RLS mal configuré — n'a rien de spécifique à la vitrine. N'importe quelle app Supabase générée sans durcissement manuel du RLS peut être exposée. Le seul moyen de savoir, c'est de tester.
Le scanner de sécurité de Lovable ne me protège pas ?
Pas suffisamment. Il vérifie qu'une politique RLS existe, pas qu'elle filtre réellement. Une politique mal écrite passe le test et laisse fuiter les données. Un audit qui interroge réellement l'API en anon est le seul moyen fiable de constater l'exposition.
Combien de temps pour sécuriser une app Lovable ?
Une sécurisation ciblée (RLS, accès, rotation de clés) se mesure en jours, pas en semaines, quand la base est saine. Une reprise complète vers un outil qui scale relève d'un projet de MVP sur mesure. L'audit gratuit permet de cadrer précisément avant tout devis.
Vos checks touchent-ils à mes données ?
Non. Tout est en lecture seule et non destructif. On constate ce qui est accessible sans authentification — on ne modifie rien, on n'exploite rien, et on ne conserve pas les données exposées, uniquement le constat (« telle table est lisible »). On demande aussi une attestation que vous êtes propriétaire de l'app ou autorisé à la faire auditer.
Ce qu'on en retient
- 1 app Lovable sur 10 de la vitrine officielle fuyait ses données — CVE-2025-48757, RLS mal configuré.
- La clé anon est publique : vos tables sont interrogeables sans login dès que le RLS flanche.
- Le "security scan" natif vérifie la présence du RLS, pas son efficacité — fausse assurance.
- Lovable reste excellent pour un site ou un proto — la ligne, c'est le moment où l'app porte des données réelles.
- Tester la surface anon est gratuit, rapide et non destructif — c'est le seul moyen de savoir.
Vous voulez savoir où en est votre app ? Lancez l'audit de sécurité — l'URL suffit, on vous renvoie le rapport le jour même. Ou parlez-en avec nous en 30 minutes si vous envisagez de reprendre la main sur votre outil.