Si vous utilisez GitHub Copilot ou ChatGPT pour coder plus vite, voici une nouvelle qui va peut-être vous refroidir un peu. Une fintech a découvert que des attaquants avaient extrait des données clients via un endpoint API qui n'était documenté nulle part. Personne dans l'équipe ne se souvenait l'avoir créé et après 3 semaines d'enquête, le verdict est tombé : c'est Copilot qui l'avait généré pendant une session de code nocturne.

Bienvenue dans l'ère des "phantom APIs" les amis !

J'avoue que le concept m'a fait marrer car on parle quand même d'endpoints qui existent en production mais dont personne n'a connaissance. Ahahaha... y'a pas de documentation, pas de tests, pas de validation de sécurité. C'est juste un peu de code généré par une IA qui a trouvé ça "logique" de créer un /api/v2/admin/debug-metrics qui balance du PII à quiconque tombe dessus par hasard.

J'ai vu le dernier rapport Veracode GenAI Code Security et les chiffres font un peu flipper c'est vrai ! Ils ont testé plus de 100 LLM sur 80 tâches de codage différentes, et le résultat fait mal puisque 45% du code généré par IA contient des vulnérabilités classées OWASP Top 10. En gros, presque une fois sur deux, votre assistant IA vous pond du code troué comme une passoire. Java est le grand gagnant avec 72% de taux d'échec, suivi par Python, JavaScript et C# qui tournent autour de 38-45%.

En effet, l'IA ne pense pas comme un dev qui s'est déjà fait hacker. Par exemple, quand un dev crée un endpoint, il réfléchit authentification, rate limiting, exposition de données, documentation. Alors que l'IA, elle, génère juste ce qui lui semble statistiquement logique vu son dataset d'entraînement, sans comprendre les implications sécurité ou les politiques de l'organisation.

D'ailleurs une autre étude Apiiro montre que les assistants IA ont multiplié par 10 les vulnérabilités introduites en seulement 6 mois dans les dépôts étudiés. Les chemins d'escalade de privilèges ont explosé tout comme les défauts architecturaux. Et le pire c'est que les développeurs qui utilisent l'IA exposent leurs credentials cloud (clés Azure, Storage Access Keys) deux fois plus souvent que les autres.

Y'a aussi le problème du "slopsquatting". Oui, encore un gros mot, je sais... En fait, l'IA peut vous recommander d'installer un package qui n'existe tout simplement pas. Genre elle hallucine un nom de librairie et un attaquant un peu moins con que les autres, peut enregistrer ce nom sur npm ou PyPI et y foutre du code malveillant.

Et là que ça devient vraiment problématique, c'est que les outils de sécurité traditionnels ne voient rien. L'analyse statique compare votre code à des specs documentées, sauf que les phantom APIs n'existent dans aucune spec. Les API gateways protègent les endpoints enregistrés mais laissent passer des routes non déclarées sans authentification.

Pour s'en sortir, certaines boîtes commencent donc à analyser le trafic en temps réel pour détecter les endpoints qui traînent. Y'a aussi l'audit de code spécifique IA pour repérer les patterns de génération algorithmique, et la comparaison continue entre les specs et ce qui tourne vraiment en production.

Bref, relisez votre code généré par IA comme si c'était un stagiaire collégien de 3e qui l'avait écrit, et si vous découvrez un endpoint bizarre dans votre base de code dont personne ne se souvient, y'a des chances que ce soit un "fantôme" laissé par votre copilote préféré...

Attention, si vous laissez tourner WebGoat sur votre machine, elle sera “extrêmement vulnérable aux attaques”. C’est en tout cas ce qui est écrit en gros sur la page de ce projet OWASP , et c’est pas pour faire joli car WebGoat est une application web délibérément pourrie, truffée de failles de sécurité, créée exprès pour que cous appreniez à les exploiter.

Et c’est génial !!

Car on a enfin un truc qui nous permet d’apprendre vraiment comment les hackers s’infiltrent dans les sites web, sans risquer de finir au tribunal. Parce que bon, scanner le site de votre voisin pour “apprendre”, c’est direct trois ans de prison et 100 000 euros d’amende. Alors qu’avec WebGoat, vous pouvez tout péter tranquille depuis chez vous.

WebGoat , c’est donc un projet open source maintenu par l’OWASP depuis des années qui vous propose uune application web qui ressemble à n’importe quel site lambda, sauf qu’elle est bourrée de vulnérabilités volontaires telles que des injections SQL, XSS, CSRF, contrôle d’accès défaillant… bref, toutes les saloperies du Top 10 OWASP sont là, prêtes à être exploitées.

Et WebGoat fonctionne comme un cours interactif car pour chaque vulnérabilité, vous avez trois étapes : d’abord on vous explique comment ça marche, ensuite vous devez l’exploiter vous-même via des exercices pratiques, et enfin on vous montre comment corriger le problème. On apprend en faisant !

D’après la doc officielle , WebGoat couvre presque toutes les vulnérabilités du Top 10 OWASP. Pour ceux qui ne savent pas, le Top 10 OWASP c’est LA référence mondiale des failles de sécurité web.

Au sein de WebGoat se cache aussi WebWolf, une application séparée qui simule la machine de l’attaquant. Ça tourne sur le port 9090 pendant que WebGoat tourne sur le 8080, comme ça, vous avez vraiment la séparation entre ce qui se passe côté victime et côté attaquant. WebWolf vous permet également d’uploader vos payloads ou outils, de recevoir des données exfiltrées, et même de simuler un serveur mail pour les attaques de phishing.

Et pour installer tout ça, le plus simple c’est Docker :

docker run -it -p 127.0.0.1:8080:8080 -p 127.0.0.1:9090:9090 webgoat/webgoat

Ou si vous préférez la version standalone avec Java :

java -Dfile.encoding=UTF-8 -jar webgoat-2025.3.jar

Une fois lancé, vous accédez à WebGoat sur http://localhost:8080/WebGoat et WebWolf sur http://localhost:9090/WebWolf. Vous vous créez un compte (c’est juste en local, pas de panique) et c’est parti pour les exercices !

Les leçons sont vraiment bien foutues. Prenez l’injection SQL par exemple. D’abord on vous montre comment une requête SQL mal protégée peut être détournée. Ensuite vous devez exploiter la faille pour voler des numéros de cartes bancaires (fausses, hein), et à la fin, on vous explique comment utiliser les prepared statements pour éviter ce genre de conneries.

Et n’allez pas croire que ça s’adresse uniquement aux pro. Non, les débutants ont des exercices guidés avec des indices, et les plus avancés ont des “challenges” sans aucune aide semblables à des CTF (Capture The Flag).

Et pour les développeurs, c’est vraiment un super outil pour comprendre pourquoi votre chef de projet vous casse encore les pieds avec la sécurité ! Car, croyez-moi, une fois que vous avez réussi à dumper toute une base de données avec une simple apostrophe dans un formulaire, vous ne regardez plus jamais les entrées utilisateur de la même façon.

Attention quand même, WebGoat n’est pas un jouet. Les techniques que vous apprenez sont réelles et fonctionneront sur de vrais sites mal sécurisés. D’ailleurs, l’OWASP est très clair là-dessus : “Si vous tentez ces techniques sans autorisation, vous allez très probablement vous faire choper”. Et n’oubliez pas, comme vous ne faites partie d’aucun parti politique, pour vous y’aura vraiment de la zonzon.

D’ailleurs, petite conseil, quand vous faites tourner WebGoat, coupez votre connexion internet ou au moins assurez-vous qu’il n’écoute que sur localhost, parce que si quelqu’un d’autre sur votre réseau découvre que vous avez une application volontairement vulnérable qui tourne… Disons que ça pourrait mal finir ;-).

Ah et WebGoat s’intègre super bien avec d’autres outils de sécurité. Ça permet du coup de se former aussi dans la foulée sur Burp Suite, OWASP ZAP, ou SQLMap.

Bref, installez WebGoat ce weekend et amusez-vous à tout casser. Vous m’en direz des nouvelles !!

Et un grand merci à Letsar pour l’info !