Lovable est-il sûr ? Ce que 18 554 applications Lovable ont montré

Vous avez construit quelque chose sur Lovable, ça marche, et vous êtes sur le point d’y mettre de vraies personnes. Quelque part dans cette semaine, vous avez tapé « lovable est-il sûr » dans un champ de recherche, et ce qui est revenu était soit une page sur une divulgation de sécurité de 2025, soit un éditeur qui voulait vous vendre un scan. Aucune des deux ne parlait de l’application que vous êtes sur le point de publier.

Voici ce que la plupart de ces réponses ratent : « Lovable est-il sûr » est trois questions dans une seule phrase, et celle qui décide si des inconnus peuvent lire les données de vos utilisateurs est celle que presque personne ne mesure.

Nous pouvons la mesurer. Entre le 12 et le 14 août 2026, nous avons passé 30 998 applications en ligne par les neuf mêmes vérifications externes que n’importe qui peut lancer gratuitement sur notre page d’accueil, et 18 554 d’entre elles étaient publiées sur Lovable. C’est notre plus grande cohorte, trois applications sur cinq parmi toutes celles que nous avons scannées. Voici ce qui est revenu pour elles, et où s’arrête notre vue.

Lovable est-il sûr ?

Comme plateforme, oui, et avec une marge plus large que prévu. Ce que Lovable produit lui-même était le plus propre des cinq constructeurs mesurés. Tout ce qui a décidé d’une note était dans l’application construite par son propriétaire.

Imaginez une boutique dont la réserve est de l’autre côté de la rue. Lovable construit la boutique : les vitrines, le comptoir, l’enseigne. Supabase possède la réserve, et elle a sa propre serrure sur sa propre porte. Ce que la boutique tend à un passant est une question. Ce que la réserve tend à quiconque vient demander en est une tout autre, et aucun rangement de la boutique n’y change rien.

1. La plateforme. Lovable publie-t-il votre application correctement : un certificat valide, un domaine qui n’expire pas, rien qui fuie du build. C’est la boutique.
2. L’agent. Le code écrit par l’IA de Lovable tient-il la route. Aucun scan externe ne voit le câblage, et cet article le dit plutôt que de le deviner.
3. L’application que vous avez publiée. Ce qu’un inconnu atteint depuis le trottoir : une clé dans le code qu’un navigateur télécharge, un bucket de stockage qui liste ses fichiers, une table de base qui répond à quiconque demande.

Nos vérifications lisent la troisième et deux parties de la première. Côté plateforme, le certificat était valide sur les 18 486 applications où nous avons pu en lire un, et aucun domaine sur 18 554 n’approchait de l’expiration. Côté agent, nous n’avons rien à mesurer. Côté application, nous avons 18 554 réponses.

Ce que nous avons trouvé dans 18 554 applications Lovable

Neuf vérifications, depuis l’extérieur, sans connexion et sans accès au compte de qui que ce soit. Nous n’avons jamais lu une ligne : là où une base répondait, nous avons demandé combien de lignes elle livrerait et nous nous sommes arrêtés là. Aucune application n’est nommée ici ni ailleurs dans ce que nous publions. Chaque part ci-dessous porte sur les applications où la vérification a répondu, parce qu’une vérification qui n’a pas pu aboutir est inconnue plutôt que réussie, et c’est cette règle qui fait bouger les dénominateurs. La méthode et les données sont dans le rapport.

Les notes : 15 963 A, 370 B, 1 814 C, 402 D et 5 F. Neuf applications n’avaient aucune trouvaille du tout.

Cette première ligne explique pourquoi « 99 % des applications Lovable ont un problème de sécurité » est une phrase que vous lirez quelque part et devriez ignorer. Les en-têtes de sécurité du navigateur sont envoyés par ce qui sert votre page, et sur votreapp.lovable.app c’est Lovable, d’où la même réponse pour toutes les applications de cet hôte. Ils valent le coup et ils ne sont pas ce dont un D est fait.

Retirez cette ligne et 15 453 des 18 554 applications n’avaient rien d’autre. Les 3 092 restantes sont le reste de cet article.

Ce que Lovable fait bien, et c’est l’essentiel de la liste

Trois des chiffres ci-dessus sont les meilleurs que nous ayons relevés chez un constructeur, et tous les trois sont décidés par la plateforme et non par vous.

Les source maps. 225 applications Lovable sur 18 553 publient les fichiers d’origine derrière l’application, commentaires compris. C’est environ 1 sur 80. Chez Base44, la même vérification se déclenche sur 59 % des applications, et chez Replit sur 6 %. Le build de production de Lovable fait ce qu’il faut par défaut, donc ce point n’est le plus souvent pas votre problème.

Les en-têtes cross-origin. Zéro application sur 18 518 a dit à un site quelconque du monde qu’il pouvait appeler son API, et zéro l’a autorisé avec les cookies de connexion du visiteur. C’est la trouvaille qui laisse le plus facilement un autre site agir comme votre utilisateur, et sur Lovable elle n’est pas apparue une seule fois.

Les fichiers privés égarés. Zéro application sur 18 442 servait un .env ou un .git/config depuis une URL ordinaire. Une application Lovable n’a pas de serveur à elle à mal configurer, donc il n’y a pas de fichier oublié à l’arrière.

Rien de tout cela n’est un lot de consolation. C’est la partie du travail à laquelle vous n’avez pas eu à penser et à laquelle, chez la plupart des autres constructeurs, quelqu’un pense.

Le seul chiffre qui compte : 2 017 sur 3 553

Parmi les applications Lovable dont nous avons pu réellement interroger la base Supabase, 57 % ont livré des lignes à une requête ne portant aucune connexion.

Les dénominateurs méritent d’être parcourus, parce que c’est le chiffre que tout le monde cite et que presque personne ne cadre. Sur 18 554 applications Lovable, 6 532 nommaient un projet Supabase dans le code livré. Parmi elles, 3 553 ont répondu assez bien pour que nous puissions juger, et les 2 979 autres non : elles sont donc inconnues plutôt que propres. Sur ces 3 553, 2 017 ont rendu des lignes à un inconnu.

Dans 373 de ces applications, la table qui répondait portait un nom de personnes : users, profiles, orders, messages. Ce sont 373 applications, pas 373 tables. Dans les 1 644 autres, c’était quelque chose que nous ne pouvions pas nommer depuis l’extérieur : peut-être un catalogue produit destiné à être public, peut-être tout autre chose.

Mesurés sur toutes les applications Lovable scannées plutôt que sur le sous-ensemble jugeable, 2 017 sur 18 554 font environ 11 sur 100. Gardez ce chiffre en tête pour deux sections.

Pourquoi cela retombe sur la base et non sur Lovable

À cause d’un choix de conception correct, délibéré, et presque jamais expliqué à la personne qu’il concerne.

Une application Lovable n’a pas de serveur à elle. La page dans le navigateur du visiteur parle directement à Supabase, ce qui explique qu’on puisse bâtir l’ensemble en un après-midi et que si peu de ces applications aient une route d’API ouverte : il n’y a pas d’API à vous à laisser ouverte. Pour que cela fonctionne, l’adresse de votre base et une clé pour y accéder doivent être inscrites dans l’application, là où n’importe qui peut les lire. Cette clé est la clé publiable, et le fait qu’elle soit publique est correct. Elle est censée être là.

Ce qui veut dire que la seule chose entre un inconnu et votre table users est un réglage Supabase par table appelé Row Level Security. Activé et accompagné d’une policy, la clé publique ne lit que les lignes autorisées par cette policy. Désactivé, la clé publique lit la table.

Maintenant la partie qui décide de la plupart des projets Lovable. Supabase active Row Level Security par défaut pour les tables créées en cliquant dans le Table Editor. Les tables créées en exécutant du SQL ne l’ont pas, et exécuter du SQL est la façon dont un constructeur crée des tables pour vous. La forme habituelle d’un projet Lovable est donc : quelques tables faites à la main, qui sont protégées, à côté de celles qui ont été générées, qui ne le sont peut-être pas. Les deux sont identiques à l’œil. Aucune ne se plaint. L’application marche parfaitement dans les deux cas, et c’est tout le problème : rien, vu de devant, ne vous dit laquelle vous avez.

La version longue, avec le SQL, est ici, et le guide en langage clair pour cette plateforme est votre application Lovable est-elle sûre.

La policy qui efface l’erreur et laisse la table ouverte

Activer Row Level Security est l’étape un sur deux, et c’est à l’étape deux qu’un assistant IA fait très volontiers la mauvaise chose.

Le réglage activé et aucune policy écrite, votre propre application cesse de fonctionner. Vous obtenez une erreur, vous la collez dans le chat, et il revient quelque chose qui fait disparaître l’erreur. Très souvent, c’est une policy qui autorise tout le monde, écrite using (true). C’est une policy valide. Elle satisfait l’exigence qu’une policy existe. Elle autorise chaque ligne à chaque requête.

Le tableau de bord annonce désormais la table comme protégée, l’erreur a disparu, votre application marche, et la table est exactement aussi lisible qu’avant. Nous avons un article entier là-dessus parce que c’est l’échec le plus convaincant de toute la pile : RLS est activé et votre table est toujours publique.

Si vous avez déjà collé une erreur de Row Level Security dans une fenêtre de chat et accepté le premier correctif qui a fait passer le build, allez lire cette policy aujourd’hui.

CVE-2025-48757, et pourquoi ce n’est plus votre question

Elle est réelle, elle était sérieuse, et côté Lovable elle est close depuis plus d’un an. Elle n’est pas non plus ce que vous devriez chercher.

En mai 2025, le chercheur en sécurité Matt Palmer a publié CVE-2025-48757, sur des applications Lovable dont les tables Supabase avaient une Row Level Security absente ou écrite trop largement. Il a scanné 1 645 applications Lovable et en a trouvé 170 avec des bases exposées. La réponse de Lovable a été d’ajouter une vérification de sécurité qui tourne avant publication et avertit des tables non protégées.

Voici la lecture honnête, et c’est pourquoi la CVE est le mauvais cadre. Cette divulgation a trouvé environ 10 applications exposées sur 100. Seize mois plus tard, sur une cohorte onze fois plus grande, nous en avons trouvé environ 11 sur 100. Les dénominateurs ne sont pas identiques et aucun des deux échantillons n’est l’internet entier : prenez les deux comme le même ordre de grandeur plutôt que comme une comparaison précise. La direction est assez claire : le taux n’a pas baissé.

Ce n’est pas un correctif qui a échoué. C’est le signe que ça n’a jamais vraiment été une vulnérabilité dans un produit. C’est un réglage sur vos propres tables, dans votre propre projet Supabase, que personne d’autre ne peut activer à votre place. Un correctif n’y arrive pas, et c’est exactement pour cela qu’une vérification que vous lancez vous-même y arrive.

De quoi les 822 clés étaient réellement faites

Presque toutes allaient bien, et un scanner qui vous dirait le contraire vous apprendrait à l’ignorer.

822 des 18 554 applications Lovable avaient quelque chose en forme de clé dans le code qu’un visiteur télécharge. Lu comme une liste de formes, cela fait 4 % des applications qui « fuient des secrets ». Lu comme ce que chaque clé peut réellement faire, cela ressemble à ceci :

Les 727 clés Google sont la raison pour laquelle nous classons au lieu de simplement reconnaître des formes. Une clé Google Maps dans un navigateur est là où elle doit être, et le correctif est de la restreindre à votre propre domaine plutôt que de paniquer.

Ce sont les quatre dernières lignes qui comptent, et elles sont rares : 30 applications sur 18 554. Ce sont aussi les trouvailles qui coûtent de l’argent toutes seules, et elles font surface le plus souvent sous forme de facture avant que quiconque ait remarqué quoi que ce soit. Deux détails pour le procès-verbal. Les trois clés service_role de tout le scan sur 30 998 applications étaient dans des applications Lovable, et deux des trois secrets Stripe en production aussi. Une clé service_role dans un navigateur rend chaque policy Row Level Security de votre projet sans objet en une ligne, ce qui en fait la seule trouvaille que nous classons critique à vue, et celle qu’il faut faire tourner le jour même.

Distinguer les deux sortes prend environ une minute, et nous avons écrit le guide.

Les 768 buckets de stockage que personne ne voulait ouvrir

Un bucket Supabase marqué public ne sert pas seulement les fichiers que votre application référence. Il liste aussi chaque fichier qu’il contient à quiconque le demande.

768 des 16 565 applications Lovable vérifiables avaient au moins un bucket qui listait son contenu. La raison est la même que pour les tables lisibles : rendre un bucket public est la façon de faire apparaître une image, cela marche tout de suite, et rien ensuite ne vous dit que le listage est venu avec. Factures téléversées, photos de pièces d’identité et avatars d’utilisateurs finissent tous au même endroit. Ce qu’un bucket public expose réellement couvre le correctif, qui est des URL signées plutôt qu’un bucket privé dont vous ne pourrez plus lire le contenu.

La vérification de cinq minutes sur votre application Lovable

Chaque point est une page que vous ouvrez. Utilisez une fenêtre privée pour que votre propre connexion ne réponde pas à la place d’un inconnu.

1. Supabase → Authentication → Policies. Parcourez la liste. Toute table affichant Row Level Security désactivée est lisible par quiconque a l’adresse de votre projet, laquelle est inscrite dans votre application.
2. Lisez les policies des tables où c’est activé. Si l’une d’elles autorise tout le monde, la table est ouverte et le tableau de bord la dit quand même protégée.
3. Supabase → Storage. Tout bucket marqué public liste ses fichiers à quiconque. Regardez ce qu’il contient avant de décider que c’est acceptable.
4. Supabase → Settings → API. Confirmez que la clé livrée par votre application est la clé publiable. Si une clé secrète a un jour été collée dans le projet, faites-la tourner là avant de la supprimer du code, parce que l’ancienne valeur fonctionne jusque-là.
5. Ou laissez le scan le faire. Il lance ces quatre points depuis l’extérieur et cinq autres, prend environ 20 secondes, ne demande aucun compte, et vous montre une note et ce qui l’a produite : scanner votre application.

Si vous préférez parcourir toute la surface comme une liste, la checklist de sécurité en 10 minutes couvre ce qu’il vaut la peine de confirmer sur toute application fraîchement lancée, et n’importe qui peut-il lire votre base Supabase est le test à faire si vous ne faites qu’une seule chose.

Votre application change à chaque publication

Un scan lancé le mois dernier décrit l’application du mois dernier, et sur Lovable c’est un mois plus court qu’ailleurs.

Publier est un clic, donc un changement est en ligne dès que vous l’acceptez. Il n’y a aucune étape de déploiement entre vous et internet pour rattraper une table ajoutée ce matin sans Row Level Security, ou une clé collée dans le chat à minuit pour passer un build qui échouait. Chacune des 2 017 bases exposées que nous avons trouvées appartenait à quelqu’un dont l’application marchait très bien.

Reeve Monitor est la version de cet article qui se lance toute seule. Il relance les neuf vérifications toutes les heures sur jusqu’à trois applications, regarde toutes les 60 secondes si l’application répond, vous prévient quand un résultat change plutôt que d’attendre que vous regardiez, et envoie un rapport mensuel. Il coûte €12 par mois au tarif public, avec sept jours gratuits avant tout prélèvement ; la page de tarifs est parfois en dessous du chiffre indiqué ici et jamais au-dessus.

Si votre application Lovable utilise Supabase, et 6 532 des 18 554 scannées le font, l’autre moitié du problème est la copie. Une table exposée est une chose qu’un inconnu peut lire. Un agent avec accès à la base, ou une migration partie dans le mauvais sens, est une chose qui peut l’effacer, et la sauvegarde quotidienne de Supabase sur l’offre gratuite n’est pas quelque chose que vous pouvez restaurer vous-même. Reeve Care prend chaque nuit une copie chiffrée de votre base Supabase, la garde là où votre projet ne peut pas l’atteindre, vérifie que chaque copie se restaure réellement, et vous donne une restauration en un clic le jour venu. Tout ce que fait Monitor est inclus. Care coûte €49 par mois au tarif public pour une application, avec les mêmes sept jours gratuits.

La forme de ce second échec, racontée par quelqu’un à qui c’est arrivé, est le jour où un agent IA a effacé une base de production. Aucune des neuf vérifications de cet article n’aurait aidé là. Une copie, si.

Ce qu’il faut faire cette semaine

Lovable a bien fait sa moitié. Les 2 017 sont la moitié qui vous appartient, et c’est un réglage plutôt qu’une réécriture. Si vous voulez plutôt la comparaison entre constructeurs, quel constructeur d’applications IA est le plus sûr a le tableau pour les cinq.