Scanner de sécurité vibe coding : ce qu’un scan d’URL rate

Vous collez l’adresse de votre app dans un scanner, vous attendez une vingtaine de secondes, et une lettre revient. A, peut-être C. Puis arrive la question qui compte vraiment : est-ce que ça veut dire que mon app va bien ?

Voici la partie que la plupart des outils de cette catégorie vous laissent deviner. Un scanner de sécurité vibe coding lit votre app depuis la rue. Il voit ce que voit le navigateur de n’importe quel visiteur, ce qui fait beaucoup, et il s’arrête à votre porte d’entrée. Ce que votre serveur fait en privé reste privé pour lui aussi.

Savoir où passe cette ligne, c’est ce qui rend un scan utile. Un A vous dit que les portes donnant sur la rue étaient fermées au moment où nous avons regardé, et il ne dit rien du tout sur la pièce derrière.

Qu’est-ce qu’un scanner de sécurité vibe coding ?

Un outil qui charge votre app en ligne comme le ferait un visiteur, puis lit ce qui est revenu.

Vous lui donnez une URL. Il ne demande ni votre code source, ni votre dépôt, ni le mot de passe de votre base, ni un compte chez le builder que vous avez utilisé. Il récupère votre page, laisse tourner le JavaScript pour voir le code que votre app livre réellement, lit les en-têtes arrivés avec la réponse, examine votre certificat, et pose à votre base de données et à votre stockage de fichiers quelques questions que n’importe quel inconnu pourrait poser.

Puis il note ce qui a répondu. C’est toute la forme de la chose, et c’est pourquoi cela prend vingt secondes au lieu d’une semaine.

Cette catégorie existe parce que les apps construites avec Lovable, Bolt, v0, Cursor, Replit, Windsurf et Base44 déraillent aux mêmes rares endroits, et presque tous ces endroits sont visibles depuis l’extérieur. Une clé secrète dans le bundle. Une table qui répond à un inconnu. Un bucket de stockage qui liste son propre contenu. Personne n’a besoin de votre source pour trouver l’un d’eux, parce que votre app les tend à chaque visiteur par construction.

Ce qu’un scan lit réellement

Cinq surfaces, et vos propres visiteurs en téléchargent quatre sans le remarquer.

Le bundle est celui qui surprend. Le code de votre app doit arriver dans le navigateur avant de pouvoir y tourner, donc chaque clé qu’il contient arrive aussi, avec les chemins d’API qu’il appelle et souvent les noms des tables qu’il lit. Un scanner appuie sur le même F12 qu’un visiteur curieux. Il est seulement plus rapide, et il lit tous les fichiers au lieu du premier.

La question posée à la base de données est celle que tout le monde imagine intrusive, et c’est la plus douce de la liste. Pour savoir si une table est lisible par des inconnus, le nôtre demande à l’API un décompte des lignes et lit le nombre dans un en-tête de réponse. Un décompte supérieur à zéro signifie que ces lignes sont atteignables. Aucune ligne n’est jamais récupérée, et la clé avec laquelle il demande est la clé publiable déjà présente dans votre bundle, qui est censée y être.

Les quatre choses qu’un scan d’URL ne peut pas voir

Tout ce qui se passe sur votre serveur, parce que rien de cela n’est jamais envoyé à un navigateur.

Votre code serveur. Edge functions, routes d’API, fonctions de base de données, tout ce qui tourne dans Supabase ou chez votre hébergeur. Un scanner peut appeler un point d’entrée et lire ce qui revient. Il ne peut pas lire le code qui l’a produit, donc une erreur qui n’apparaît que sur certaines entrées reste invisible.

Vos variables d’environnement. Les clés que vous avez gardées sur le serveur, et c’est exactement leur place. Un scan peut vous dire qu’il n’a trouvé aucun secret dans votre bundle. Il ne peut pas confirmer que le secret est bien rangé, parce qu’il ne voit jamais l’endroit où vous l’avez rangé.

Votre historique de versions. Une clé commitée en mars et retirée en avril a disparu de votre app et se trouve toujours dans votre dépôt. Quiconque peut voir ce dépôt peut encore la lire, et aucun examen de votre site en ligne ne la fera remonter.

La logique de votre app. Si un utilisateur connecté peut ouvrir la commande d’un autre en changeant un chiffre dans l’adresse. Si un formulaire acceptera un prix envoyé par le navigateur. Ce sont des décisions que votre app prend sur ce qu’elle autorise, et les attraper demande de se connecter et d’essayer des choses, ce qui est un test d’intrusion.

Il y a une cinquième limite qui nous appartient plutôt qu’à la catégorie, et il vaut la peine de la connaître avant de lire un de nos rapports. Supabase ne sert plus la liste des tables d’un projet à une clé publiable, un scanner n’a donc aucun moyen de demander comment vos tables s’appellent. Le nôtre travaille à la place avec trois sources : l’index du projet sur les projets plus anciens où il répond encore, les noms de tables qu’il trouve dans votre propre bundle, et une liste de vingt-six noms courants dans les apps vibe codées. Une table ouverte portant un nom inhabituel qui n’apparaît jamais dans votre code frontend est une table que nous n’atteindrons pas. L’advisor de Supabase l’atteint, et c’est la comparaison deux sections plus bas.

Un scan propre veut-il dire que mon app est sûre ?

Non. Cela veut dire que chaque question que le scan pouvait poser depuis l’extérieur est revenue propre, et c’est une phrase plus petite qu’elle n’en a l’air.

Une partie de la raison tient aux quatre angles morts ci-dessus. L’autre partie tient à ce qu’une vérification peut finir de trois façons et qu’une seule est une réussite. Une vérification trouve quelque chose. Une vérification demande et obtient un non clair. Ou une vérification n’obtient aucune réponse, parce que la requête a expiré, que l’hôte l’a refusée, ou que la page n’a jamais fini de charger.

Cette troisième fin décide si l’on peut faire confiance à un rapport, et c’est la plus facile à arrondir discrètement en coche. Le nôtre écrit « Impossible à vérifier » sur la ligne et laisse votre note tranquille. Une fausse coche serait la chose la plus nuisible que ce scanner puisse afficher, parce que vous agiriez dessus.

C’est cette même honnêteté qui rend nos propres chiffres publiés moins alarmants qu’ils n’en ont l’air. Entre le 12 et le 14 août 2026 nous avons passé ces vérifications sur 30 998 apps vibe codées en ligne, et 99 % sont revenues avec au moins un constat. Presque tout cela tient en une seule ligne : des en-têtes de sécurité du navigateur que la plateforme d’hébergement ne pose jamais, et que la plupart des propriétaires sur un sous-domaine de builder ne peuvent pas activer eux-mêmes. Les compter est correct. Lire 99 % comme « presque toutes les apps sont en danger » ne l’est pas.

Scan d’URL, scan de dépôt, ou l’advisor de Supabase ?

Ils lisent trois choses différentes, la question utile est donc lequel peut voir le problème que vous avez.

Ils se recouvrent bien moins que les noms le laissent croire. L’advisor de Supabase parcourt votre projet et signale des problèmes de configuration, dont les tables dont la Row Level Security est mal réglée. Un scan d’URL lit la conséquence, à savoir si ces lignes arrivent chez des inconnus en ce moment. Les deux se séparent plus souvent qu’on ne le croirait, parce qu’activer le réglage ne revient pas à être protégé.

Un scanner de dépôt est le seul des trois qui puisse trouver la clé que vous avez supprimée le mois dernier. C’est aussi le seul qui ne puisse pas vous dire si le code qu’il vient de lire est celui que vous avez déployé.

Comment lire la note

La lettre est plafonnée par le pire constat du rapport, un bon score ne rattrape donc jamais un constat grave.

Chaque scan démarre à 100. Un constat critique coûte 40 points, un élevé 15, un moyen 5, un faible 1. Puis un plafond se pose sur l’arithmétique : un constat critique plafonne la note à D, deux la plafonnent à F, et un seul constat élevé la plafonne à C. Une app par ailleurs impeccable avec une seule table ouverte ressort en D, et c’est le comportement voulu.

Ce que vous avez bien fait figure au rapport et ne vous coûte rien. Votre clé Supabase publiable présente dans votre bundle est listée comme correcte, parce que c’est sa raison d’être, et la peindre en rouge est la façon dont un outil vous apprend à ignorer le rouge.

Que faire d’un résultat de scan

Notre scanner de sécurité de site gratuit exécute neuf vérifications en lecture seule sur n’importe quelle URL en ligne, en une vingtaine de secondes, sans compte. Il lit, il n’écrit jamais, et il ne se connecte jamais.

Si vous préférez d’abord y aller à la main, la checklist de sécurité en 10 minutes couvre le même terrain dans l’ordre où cela vaut la peine.