Hardening vibe-coded web applications with an automated security-audit skill: a controlled comparison of two builds of the same app

Imaginez que vous construisez une maison, mais au lieu de poser les briques vous-même, vous demandez à un robot incroyablement rapide et talentueux de le faire. Vous donnez au robot une phrase simple comme : « Construis-moi un cottage douillet avec une porte rouge », et en quelques secondes, il vous remet une maison au look parfait. C'est le monde du « vibe coding » (codage par l'ambiance), où l'intelligence artificielle (IA) écrit des applications entières et fonctionnelles à partir de courtes instructions. C'est comme de la magie : vous obtenez un produit fini instantanément. Mais il y a un piège : le robot est excellent pour rendre les choses jolies et les faire fonctionner rapidement, mais il oublie souvent les aspects de sécurité invisibles et ennuyeux. Il pourrait laisser la porte d'entrée déverrouillée, oublier d'installer des détecteurs de fumée ou laisser le portail arrière grand ouvert, car ces éléments ne rendent pas la maison attrayante lors d'une visite rapide.

Dans le monde de la sécurité informatique, ces lacunes invisibles sont appelées vulnérabilités. Considérez-les comme des fissures cachées dans les fondations ou des fenêtres qui ne se verrouillent pas. Pour une équipe de professionnels, il existe des gardiens de sécurité (des experts humains) qui vérifient ces points avant que quiconque n'emménage. Mais pour le bâtisseur solitaire utilisant l'IA, il n'y a personne d'autre pour vérifier. Le robot vous remet simplement les clés, et le bâtisseur pourrait même ne pas savoir que la maison est dangereuse. Ce document pose une question simple et cruciale : si nous construisons exactement la même maison deux fois — une fois avec le robot seul, et une autre fois avec le robot plus un robot « inspecteur de sécurité » qui vérifie son propre travail — à quel point la seconde maison devient-elle plus sûre ? Les chercheurs ont voulu voir si l'ajout d'un simple contrôle automatisé pouvait transformer une application fragile et peu sûre en une forteresse sans ralentir le plaisir et la rapidité de la construction par « vibe coding ».

L'expérience : Deux applications, une seule grande différence

Les chercheurs ont mis en place une expérience contrôlée utilisant un faux magasin en ligne appelé « Northwind ». Ils ont demandé à une IA de construire ce magasin deux fois. La première version, appelons-la App A, a été construite avec le robot seul. La seconde version, App B, a été construite avec le même robot, mais cette fois, le robot avait une spécial compétence d'« audit de sécurité » attachée à lui. Cette compétence est comme un inspecteur infatigable qui exécute une boucle en cinq étapes : il scanne le code, signale les problèmes, les corrige, puis scanne à nouveau pour s'assurer que la correction a réellement fonctionné.

La clé de cette expérience était que la seule différence entre les deux applications était cette compétence de sécurité. Le prompt donné à l'IA était identique, et les fonctionnalités de base (les produits, le panier d'achat, le paiement) étaient exactement les mêmes. Cela garantissait que toute différence de sécurité ne provenait pas d'un coup de chance de l'IA ou d'un changement de conception, mais purement de l'inspecteur de sécurité.

Les résultats : Un boost de sécurité massif

Les résultats ont été spectaculaires. Lorsqu'ils ont noté les deux applications sur une échelle de 100 basée sur 16 règles de sécurité différentes (comme avoir une « Politique de sécurité du contenu », qui est un carnet de règles indiquant au navigateur quels scripts il est autorisé à exécuter, et une « Politique de référent », qui empêche l'application de divulguer votre historique de navigation à d'autres sites), la différence était énorme.

• App A (Sans compétence de sécurité) : Elle a obtenu un score de 58 sur 100. Elle présentait 16 problèmes de sécurité, dont quatre écarts de « haute sévérité ». Ces derniers sont les failles dangereuses, comme l'absence de verrous sur la porte d'entrée. Le « risque » total a été mesuré à 100 unités.
• App B (Avec compétence de sécurité) : Elle a obtenu un score de 99 sur 100. La compétence de sécurité a presque tout réparé. Elle a éliminé les quatre écarts de haute sévérité et a réduit le nombre total de problèmes de 16 à seulement 1. Le risque total est passé de 100 unités à 1 unité.

En chiffres simples, la compétence de sécurité a réduit le risque non atténué de 99,0 %. Le risque restant était un contrôle spécifique qui nécessite un véritable serveur backend (que cette démo ne possédait pas), donc la compétence a honnêtement signalé qu'il s'agissait de quelque chose qui nécessitait encore l'attention d'un humain plutôt que de prétendre que c'était réparé.

Pourquoi cela importe : Le bonus du « glitch »

L'une des découvertes les plus intéressantes n'était pas seulement de stopper les hackers, mais de prévenir l'application de se briser elle-même. Les chercheurs ont découvert que si vous ajoutez simplement des règles de sécurité strictes à une application désordonnée, l'application se casse souvent. Par exemple, si vous dites à un navigateur « Aucun script externe autorisé », mais que l'application contient du code qui tente d'utiliser des scripts externes, l'application cesse de fonctionner.

La compétence de sécurité était assez intelligente pour réaliser cela. Avant d'ajouter les règles strictes, elle est retournée nettoyer le code, déplaçant les styles et les scripts aux bons endroits afin que l'application reste parfaitement fonctionnelle et esthétique. Elle a évité les « glitches » (bugs) qu'un constructeur humain pourrait ne pas remarquer avant qu'il ne soit trop tard. Elle n'a pas seulement colmaté les brèches ; elle a renforcé toute la structure pour que les règles de sécurité ne provoquent pas l'effondrement de la maison.

Ce que le document dit (et ne dit pas)

Le document est très clair sur ce qu'il ne prouve pas. Il ne prétend pas que l'application est désormais « invincible » ou que vous pouvez cesser de vous soucier de la sécurité. Les auteurs soulignent qu'il s'agit d'une démo statique (un faux magasin avec de faux paiements) et que les applications réelles avec de l'argent réel et des données utilisateurs réelles nécessitent toujours des experts en sécurité humains professionnels pour effectuer des tests d'intrusion approfondis. L'amélioration de 99 % est spécifique aux contrôles que la compétence peut automatiser dans ce type d'application.

Cependant, le document suggère fortement que pour les millions de petites applications construites par des amateurs et des développeurs solos utilisant l'IA, ce genre d'audit automatisé et intégré change la donne. Il suggère qu'en intégrant les contrôles de sécurité directement dans le flux de travail de l'IA, nous pouvons élever le « plancher de sécurité » du logiciel de manière massive, transformant ce qui était auparavant une habitude dangereuse du « vibe coding » en quelque chose de beaucoup plus fiable. L'étude conclut que cette approche est une étape peu coûteuse et à fort impact qui rend le logiciel généré par l'IA environ deux ordres de grandeur plus sûr, simplement en faisant du chemin sûr le chemin par défaut.