Scan de sécurité Lovable : ce qu’il ne peut pas prouver

Vous cliquez sur Publish dans votre application Lovable et un scan se lance avant qu’elle ne sorte. Quelques secondes plus tard il revient propre, ou il revient avec une liste, et dans les deux cas vous tenez un résultat que vous n’avez aucun moyen de juger. C’est tout ? Est-ce que ça suffit pour y mettre de vraies personnes ?

Et voici ce qu’il faut savoir avant de trancher : le scan de sécurité Lovable et un scan de votre application publiée lisent deux objets différents. L’un lit les serrures et le câblage. L’autre s’approche et abaisse la poignée. Les deux valent la peine, et seul le second fait ce que fait chaque visiteur de votre application à longueur de journée.

Lovable analyse-t-il mon application pour trouver des problèmes de sécurité ?

Oui, et il y en a deux. Les deux sont gratuits.

Le Quick scan part tout seul à chaque publication et se termine en quelques secondes. Le Deep scan lit tout le code de votre application et c’est vous qui le lancez. Les deux lisent votre projet de l’intérieur : les réglages de votre base, les règles d’accès sur vos tables, votre arbre de dépendances, votre code.

Tout ce qui suit a été lu dans la documentation de sécurité de Lovable le 24 septembre 2026. Cette fonctionnalité a changé plus d’une fois en un an, donc regardez la date de tout article qui la décrit, celui-ci compris.

Ce que vérifie le scan de sécurité Lovable

Trois domaines, sous forme d’un jeu fixe de vérifications, en quelques secondes, à chaque publication.

La documentation de Lovable les appelle revue de la base de données, audit des dépendances et vérification de serveur MCP. La revue de la base est celle qui compte pour cet article, et sa description mérite une lecture lente : elle couvre les tables sans contrôle d’accès par enregistrement, c’est-à-dire sans Row Level Security, ainsi que les règles d’accès qui laissent tout le monde passer et la protection contre les mots de passe fuités désactivée. L’audit des dépendances cherche les vulnérabilités connues dans vos paquets npm. La vérification MCP cherche un serveur MCP que votre application expose sans authentification.

Les résultats reviennent groupés par domaine et étiquetés Critical, Warning ou Info. Le scan se déclenche automatiquement depuis la boîte de dialogue de publication, et vous pouvez aussi le lancer depuis la vue Security du projet.

Certains articles appellent cela le Basic scan. Le bouton de la vue Security affiche aujourd’hui Run quick scan, donc si un article et votre écran ne sont pas d’accord sur le nom, c’est votre écran qui est à jour.

Ce que le Deep scan ajoute

Il lit tout le code de votre application, et il ne se lance pas tout seul.

Le Deep scan reprend tout le Quick scan puis regarde votre propre logique, vos permissions et vos données. Lovable liste sept domaines : contrôle d’accès et autorisation, endpoints non authentifiés et détournables, entrées non sûres et injection, secrets et identifiants fuités, paiements et facturation, authentification et sécurité des comptes, et données personnelles et sensibles exposées. Il est gratuit lui aussi.

La phrase de la documentation sur laquelle il faut vraiment agir est celle-ci : le Deep scan ne se lance pas automatiquement pendant que vous travaillez. Il se lance quand vous le lancez. Un projet où aucun n’a jamais tourné n’a jamais eu son code lu, quel que soit le nombre de publications, et la boîte de dialogue ne vous le dira pas. Les espaces de travail Enterprise peuvent planifier des Deep scans sur des projets choisis depuis le Workspace Security center, et c’est la seule configuration où cela arrive sans que quelqu’un y pense.

Lovable peut aussi tenter des corrections, pendant que vous construisez ou via Try to fix all dans la vue Security. Lisez ce qu’une correction a changé avant de l’accepter. La réparation qui fait disparaître une erreur de row level security est très souvent une policy qui laisse tout le monde passer, et cette policy satisfait la vérification en laissant la table ouverte.

La critique de 2025, et ce qui a changé

La première version de cette vérification vous disait qu’une policy existait. Elle ne vous disait pas si la policy fonctionnait, et le chercheur qui a trouvé le problème d’origine l’a écrit lui-même à l’époque.

En mai 2025, Matt Palmer a publié CVE-2025-48757, au sujet d’applications Lovable dont les tables Supabase avaient un row level security absent ou écrit trop largement. La réponse de Lovable a été la vérification avant publication. Le texte de Palmer décrivait sa limite dans une parenthèse :

La fonctionnalité Publish de Lovable aide à s’assurer que les policies RLS sont activées sur toutes les tables et signale quand elles ne le sont pas (mais n’indique pas nécessairement si elles sont suffisantes).

Cet écart a une réponse dans la documentation actuelle, qui nomme les règles d’accès qui laissent tout le monde passer parmi ce que la revue de la base signale. Rien dans cet article ne met cette affirmation à l’épreuve. Si vous voulez la tester, créez une table jetable avec une policy qui laisse tout le monde passer et regardez si le scan la nomme. La version longue du CVE est dans Lovable est-il sûr.

Ce qu’un scan de l’intérieur ne peut pas prouver

Si votre application en ligne rend des lignes à quelqu’un qui n’est pas connecté.

Une serrure peut être posée, inventoriée et correcte sur le plan, et la porte s’ouvrir quand même. Une policy est une déclaration de ce qui devrait se passer ; ce qui tranche ce qui se passe, c’est une requête. Trois façons pour une règle de figurer comme présente pendant que la table répond quand même :

• La policy laisse tout le monde passer. Écrite using (true), c’est une policy valide, elle satisfait l’exigence qu’il en existe une, et elle renvoie toutes les lignes à tout appelant.
• La policy couvre la lecture et rien d’autre. Le select est vérifié, l’insert, l’update et le delete n’ont jamais été écrits, donc n’importe qui peut écrire dans une table que personne ne peut lire entièrement.
• La condition correspond à plus de monde que prévu. Elle devait nommer un seul client et elle nomme chaque visiteur connecté, ou chaque visiteur.

Maintenant la partie qui décide comment lire un résultat vert. Vu de dehors, ces trois cas et une table sans aucune protection donnent la même réponse, c’est-à-dire des lignes. Vos utilisateurs ne les distinguent pas. Personne d’autre ouvrant votre application non plus.

Entre le 12 et le 14 août 2026 nous avons passé les mêmes neuf vérifications externes sur 30 998 applications en ligne, et 18 554 d’entre elles étaient publiées sur Lovable. Parmi les applications Lovable qui nommaient un projet Supabase, 3 553 nous ont répondu assez clairement pour être jugées, et 2 017 d’entre elles ont rendu des lignes à une requête ne portant aucune session. La méthode et chaque dénominateur sont dans le rapport.

Une mise au point honnête sur ce chiffre. Nous étions sur le trottoir, et nous n’avons aucune vue à l’intérieur de ces projets. Nous pouvons rapporter ce qu’ont répondu 2 017 applications publiées. Nous ne pouvons pas rapporter combien d’entre elles avaient lancé un scan, ni ce qu’il leur avait dit.

Votre propre application répond à la même question en une vingtaine de secondes, et vous n’avez pas à nous croire sur le côté des 2 017 où elle tombe : scanner votre application. Le scan demande à chaque table le nombre de lignes qu’un appelant sans session recevrait, lit le nombre et s’arrête là, sans récupérer une seule ligne.

Ce qu’un scan de l’extérieur ne peut pas voir

Abaisser la poignée ne vous apprend rien sur une pièce sans porte sur la rue, et il y en a quatre.

Votre arbre de dépendances npm n’est pas dans la page que télécharge un navigateur. Votre code serveur, y compris les edge functions et la question de savoir si une route vérifie qui appelle, tourne à un endroit que nous n’atteignons jamais. Une table que votre front-end ne nomme jamais nous est invisible, parce que nous trouvons les noms de tables dans le code que votre application livre, plus une courte liste de noms courants : une table que rien dans le navigateur ne touche et que personne ne devinerait n’est donc pas interrogée. Et un serveur MCP n’est pas quelque chose qu’une requête de page trouve.

Les deux scans de Lovable lisent à eux deux les quatre. Le nôtre écrit « Vérification impossible » quand il n’a pas pu répondre à une question, plutôt qu’une coche.

La ligne sur ce que votre application publiée rend à un inconnu est la raison de lancer les deux, et c’est autour d’elle que notre scan est construit. La version générale de l’endroit où s’arrête la vue de l’extérieur est dans ce qu’un scan par URL manque.

Les deux, et dans cet ordre

Le scan de l’intérieur avant de publier, celui de l’extérieur après, parce que c’est l’ordre dans lequel les deux choses se produisent.

1. Laissez le Quick scan tourner à la publication, puis lisez-le. C’est quelques secondes, et cela arrive de toute façon. Passer la boîte de dialogue sans la lire est la manière la plus courante pour un résultat Critical d’atteindre la production.
2. Lancez un Deep scan avant que quoi que ce soit de réel parte en ligne, et de nouveau après avoir ajouté la connexion, les paiements ou une table contenant des personnes. Il ne partira pas tout seul.
3. Publiez.
4. Scannez l’adresse publiée depuis l’extérieur. Le nôtre lit votre application en ligne comme le ferait un visiteur, prend une vingtaine de secondes, ne demande aucun compte, et nomme les vérifications qu’il n’a pas pu terminer : scanner votre application.

Il y a un trou dans cette séquence, et c’est celui avec lequel il faut compter. Le Quick scan tourne quand vous publiez. La plupart de ce qui ouvre une table ne passe pas du tout par la publication : vous changez un réglage dans le tableau de bord Supabase, vous acceptez à minuit une policy qu’un assistant a écrite dans une fenêtre de chat, vous créez une table ce matin et l’écran qui la lit part jeudi. Rien de tout cela n’est une publication, donc rien de tout cela ne lance un scan, et le Deep scan n’allait de toute façon jamais partir tout seul.

Reeve Monitor assure la moitié extérieure les jours où vous n’y pensez pas. Il repasse les neuf vérifications toutes les heures sur trois applications au plus, surveille si votre application répond seulement, vous dit quand un résultat change au lieu d’attendre que vous veniez regarder, et envoie un rapport à la fin de chaque mois.

Lire un résultat vert

Un résultat propre veut dire que toutes les questions que ce scan pouvait poser sont revenues propres le jour où vous l’avez lancé. Cela vaut quelque chose, et ce n’est pas un verdict sur votre application.

Lovable met la même réserve dans sa propre documentation : les outils aident à repérer les problèmes de sécurité courants et ne peuvent pas garantir une sécurité complète. Le nôtre la porte aussi, parce qu’une vérification externe automatique n’est pas un audit et qu’une liste de résultats vide n’est pas une garantie.

La seule règle à garder pour le cas où les deux se contredisent : si le scan de l’intérieur est propre et qu’un scan de l’extérieur dit qu’une table a répondu à une requête sans session, agissez sur la réponse de l’extérieur. C’est la réponse que reçoivent vos utilisateurs, et c’est celle que reçoit n’importe qui d’autre. Allez lire la policy de cette table.

Si votre application tourne sur Supabase, le guide en langage clair pour cette plateforme est votre application Lovable est-elle sûre, et les vérifications écrites sous forme de commandes à lancer vous-même sont dans le vérificateur de sécurité Supabase.

Ce qu’il faut faire cette semaine

Si votre application Lovable utilise Supabase, ouvrez une fenêtre de navigation privée et parcourez la liste sous Authentication et Policies avant vendredi. N’importe qui peut-il lire votre base Supabase est le même test écrit sous forme de commandes à coller dans un terminal.