Sécurité du vibe coding : que vérifier avant de livrer

Le vibe coding a changé qui livre du logiciel. Un prompt et un agent transforment désormais une idée en une application déployée et exposée sur Internet en un après-midi — pas d'équipe, pas de revue de code, pas de tech lead, pas d'ingénieur sécurité. C'est la magie, et c'est aussi le problème. Les vulnérabilités n'ont pas disparu en même temps que l'équipe. L'IA les écrit simplement pour vous, avec assurance, et vous les livrez.

Voilà ce que personne ne vous dit quand on vous vend l'agent : chaque garde-fou qui se tenait entre le code d'un junior et la production était une personne. Un senior qui attrapait la concaténation de chaîne SQL. Un relecteur qui demandait « attends, cet endpoint est authentifié ? ». Un tech lead qui refusait de merger une clé en dur. Le vibe coding retire ces personnes de la boucle. Un débutant saute la décennie de cicatrices qu'un senior a gagnées à la dure. Et le senior, désormais armé d'un agent, livre des applications entières qu'une équipe entière aurait jadis filtrées.

Voici donc la checklist manquante. Elle est bâtie à partir du flux de menaces que nous maintenons — 500+ vraies fuites analysées en post-mortem, sur des applications web, des API, le cloud, la chaîne d'approvisionnement logicielle et les systèmes IA — condensée en ce qu'un vibe coder doit réellement surveiller. Lisez-la une fois et vous avez la carte.

En bref — les 10 règles

Si vous ne lisez rien d'autre, intériorisez ceci. Chaque point renvoie à une section plus bas.

Ne mettez jamais un secret dans votre code. Ni dans la source, ni dans le frontend, ni commité « juste pour l'instant ».
Considérez chaque endpoint comme public jusqu'à preuve qu'il vérifie qui demande. Authentification n'est pas autorisation.
Activez la sécurité au niveau ligne (row-level security) de votre base avant de livrer, pas après la fuite.
Laissez le framework échapper et paramétrer pour vous. Ne construisez pas du SQL ou du HTML à la main à partir d'entrées utilisateur.
Traitez toute entrée utilisateur comme hostile — dans votre code et dans toute fonctionnalité IA que vous livrez.
Lisez le code que votre agent écrit. C'est vous la couche de revue désormais. Il n'y a personne derrière vous.
Vérifiez que chaque dépendance suggérée par l'IA existe avant de l'installer.
Tout par défaut en privé — buckets, bases de données, panneaux d'admin, endpoints de debug.
Renouvelez tout secret qui a un jour touché un dépôt. Supprimer le commit ne le supprime pas.
Ajoutez un vrai filtre de revue et de scan avant que le code n'atteigne la production. L'agent n'est pas un relecteur.

Pourquoi les apps vibe-codées sont particulièrement exposées

Ce n'est pas une intuition — c'est mesuré. Dans l'étude 2025 de Veracode sur le code généré par IA, 45 % des échantillons écrits par IA introduisaient une vulnérabilité de l'OWASP Top 10, avec un taux d'échec de 86 % sur le cross-site scripting. Une étude de Stanford a constaté que les développeurs utilisant un assistant IA écrivaient un code moins sûr tout en étant plus confiants qu'il était sûr — la combinaison exacte qui livre des failles. Le modèle prédit le code statistiquement probable ; le « sécurisé par défaut » n'est pas son objectif, sauf si vous l'en faites un.

Et les conséquences sont déjà dans le flux. La fuite de l'app Tea a exposé les pièces d'identité et les selfies d'utilisateurs depuis une app montée à la va-vite avec un bucket de stockage non sécurisé et des clés en dur. Une faille dans le builder no-code/IA Lovable (CVE-2025-48757) laissait les apps générées avec la row-level security désactivée par défaut, si bien que n'importe qui pouvait lire les données des autres via l'API publique. Le schéma est constant : l'app marchait, démo impeccable, et grande ouverte.

Le reste de cet article est la liste à faire / à éviter, ordonnée selon ce qui mord le plus vite les vibe coders.

1. Secrets : ne livrez jamais une clé dans votre code

C'est l'erreur de vibe coding la plus courante, et la plus dommageable. Les assistants IA alimentent activement une explosion d'identifiants fuités ; des dizaines de millions de secrets fuitent vers le GitHub public chaque année.

À éviter :

Coder en dur des clés API, des mots de passe de base de données ou des jetons sous forme de littéraux. Les scanners les trouvent en quelques secondes, et la fuite Uber (57 M d'enregistrements) comme la fuite Toyota (une clé restée cinq ans dans un dépôt public) ont toutes deux commencé exactement ici.
Mettre une vraie clé dans votre frontend ou votre app mobile. Un secret livré au client est public — n'importe qui peut lire votre bundle JS ou décompiler l'app.
Commiter un fichier .env. Les attaquants scannent Internet à la recherche de fichiers .env exposés et utilisent les clés AWS qu'ils contiennent pour prendre le contrôle et rançonner des comptes cloud entiers.
Supposer que supprimer le commit corrige le problème. Le secret reste dans l'historique git pour toujours ; quiconque a cloné le dépôt l'a encore.

À faire : Chargez les secrets depuis des variables d'environnement ou un gestionnaire de secrets à l'exécution. Ajoutez *.env et les fichiers de clés à .gitignore. Activez la détection de secrets en pre-commit et la protection de push de votre hébergeur pour qu'une clé n'atteigne jamais le distant. Et si un secret a un jour touché un dépôt, renouvelez-le immédiatement — considérez-le compromis. (Voir tous les cas de secrets dans le code →)

2. Authentification et contrôle d'accès : ne livrez pas une app publique

Une app vibe-codée qui « marche » signifie en général que le chemin heureux marche. Le défaut dangereux, c'est une API qui renvoie des données à quiconque demande, ou un endpoint qui vérifie que vous êtes connecté mais jamais que l'enregistrement est le vôtre.

À éviter :

Livrer un endpoint qui sert un enregistrement par ID sans vérifier qu'il appartient à l'appelant. C'est la Broken Object Level Authorization (IDOR), la faille d'API la plus courante, et c'est ainsi que First American a fuité 885 M de documents (il suffisait d'incrémenter le numéro dans l'URL), que Optus a perdu 9,8 M d'enregistrements clients, et que T-Mobile en a perdu 37 M.
Confondre authentification et autorisation. L'API de l'USPS exigeait une connexion mais laissait tout utilisateur connecté lire le compte de n'importe quel autre. L'API de Peloton renvoyait des profils privés à quiconque.
Faire confiance au client pour appliquer quoi que ce soit — drapeaux de confidentialité, prix, rôles utilisateur. Appliquez-le côté serveur.
Lier les corps de requête directement à votre modèle de base de données. Le mass assignment, c'est ainsi qu'un chercheur s'est donné un accès commit au dépôt Rails en renseignant un champ que le formulaire n'affichait jamais.
Laisser la row-level security désactivée (l'échec Lovable et Tea).

À faire : Appliquez l'autorisation au niveau objet à chaque requête — vérifiez le propriétaire de la ressource contre la session, à chaque fois. Exigez l'authentification sur chaque route, y compris celles que vous aviez oublié d'avoir livrées. Activez la row-level security dans Supabase/Postgres et testez l'accès anonyme contre chaque endpoint avant le lancement. Ne liez qu'une allowlist explicite de champs. (Voir tous les cas AppSec →)

3. Les bugs classiques que l'IA écrit pour vous

L'agent vous tendra, sans qu'on le lui demande, les vulnérabilités qui font la une des fuites depuis vingt ans. La bonne nouvelle : les frameworks modernes se défendent contre toutes si vous utilisez leurs défauts au lieu de laisser l'IA bricoler les siens.

Injection SQL — ne construisez jamais du SQL en concaténant des chaînes ; utilisez des requêtes paramétrées / votre ORM. (TalkTalk, Heartland, MOVEit ont tous commencé ici.)
Cross-site scripting — laissez votre framework auto-échapper ; évitez innerHTML/dangerouslySetInnerHTML ; ajoutez une Content-Security-Policy.
Injection de commande OS — ne passez pas d'entrée utilisateur dans un shell ; appelez directement les bibliothèques.
Injection de template côté serveur et désérialisation non sûre — n'évaluez ni ne désérialisez jamais une entrée non fiable.
Traversée de chemin et upload de fichier non restreint — validez et canonicalisez les chemins de fichiers ; stockez les uploads là où ils ne peuvent pas s'exécuter.
SSRF — si votre code récupère une URL fournie par l'utilisateur (webhooks, aperçus de liens, imports d'images), validez-la et bloquez les adresses internes comme 169.254.169.254.

À faire : Tenez-vous-en aux défauts sécurisés de votre framework, et passez un scanner d'analyse statique sur le code généré par IA avant le merge — ces classes sont exactement ce que les scanners attrapent.

4. Votre agent de code fait partie de la surface d'attaque

L'agent ne se contente pas d'écrire du code risqué — il peut être retourné contre vous.

À éviter :

Installer un paquet juste parce que l'IA l'a suggéré. Les modèles hallucinent des noms de paquets, et les attaquants pré-enregistrent ces noms avec un malware — c'est le slopsquatting. Vérifiez d'abord que le paquet existe réellement et est légitime.
Faire confiance aux fichiers que l'agent lit. Des instructions cachées dans un README, une dépendance, une page web ou un fichier de règles d'agent peuvent détourner l'agent pour qu'il insère une backdoor ou exfiltre vos secrets.
Laisser l'agent exécuter automatiquement des commandes shell ou merger automatiquement sa propre sortie. L'attaque supply-chain de nx a armé les CLI IA locales des développeurs eux-mêmes pour scanner et voler leurs secrets ; une extension Amazon Q empoisonnée a livré une instruction d'effacement de la machine ; un agent Replit a supprimé une base de données de production.
Donner à l'agent un accès permanent à la production. Séparez dev et prod ; refusez à l'agent l'accès en écriture aux données et clés vivantes.

À faire : Épinglez et verrouillez (lockfile) les dépendances, examinez les nouvelles, sandboxez l'exécution de l'agent, exigez une approbation avant qu'il n'exécute des commandes, et lisez chaque diff avant de l'accepter. (Voir tous les cas d'agents de code IA →)

5. Si votre app embarque une fonctionnalité IA ou un chatbot

Dès que votre app a un LLM qui lit des entrées utilisateur ou des données externes, l'injection de prompt devient votre problème. Le modèle ne peut pas distinguer vos instructions de celles d'un attaquant.

À éviter :

Concaténer l'entrée utilisateur dans votre prompt système. Le premier cas viral — le bot remoteli.io — et le bot du concessionnaire Chevrolet qui a « vendu » une voiture à 1 $ faisaient exactement cela.
Rendre la sortie du modèle comme du HTML brut. Le chatbot de Lenovo a été transformé en XSS voleur de cookies parce que sa sortie était injectée dans la page sans nettoyage.
Mettre des secrets, un .env ou des données privilégiées dans le contexte du modèle — on peut les en extraire, et un agent crypto sur X a été drainé de 150 K$ via une instruction injectée.
Laisser un agent qui lit des données non fiables (e-mails, tickets de support, leads CRM, documents) entreprendre des actions réelles sans approbation. C'est ForcedLeak (exfiltration CRM via un formulaire de lead) et EchoLeak (exfiltration zéro-clic depuis un e-mail) — le piège de l'agentivité excessive.
Oublier que vous êtes responsable de ce qu'il dit : un tribunal a tenu Air Canada responsable de la politique inventée par son chatbot.

À faire : Traitez toute entrée et tout contenu ingéré comme des données non fiables, jamais comme des instructions. Nettoyez et encodez la sortie du modèle avant de la rendre. Gardez les secrets hors du prompt. Exigez une approbation humaine pour toute action conséquente, et limitez les outils de l'agent au moindre privilège.

6. Déploiement : n'exposez pas vos données à Internet

Le vibe coding ne s'arrête pas au code — vous le déployez, et la console cloud est son propre champ de mines de défauts non sécurisés.

À éviter :

Rendre un bucket de stockage public. Des buckets lisibles par tous ont exposé 198 M d'enregistrements d'électeurs, les clés maîtresses d'Accenture et 2,4 To de données Microsoft.
Exposer une base de données à Internet. Des dizaines de milliers d'instances MongoDB ouvertes ont été effacées et rançonnées ; un serveur Git Nissan en admin/admin a fuité 20 Go de code source.
Sur-permissionner vos identifiants cloud. La fuite Capital One (106 M d'enregistrements) était une SSRF qui a lu un rôle d'instance sur-privilégié et est entrée dans S3.

À faire : Tout par défaut en privé. Activez « bloquer l'accès public » sur le stockage. Mettez les bases de données sur des réseaux privés derrière une authentification. Limitez les rôles cloud au moindre privilège, imposez IMDSv2, et ne livrez jamais ce .env. (Voir tous les cas cloud/IaC →)

7. Dépendances et chaîne d'approvisionnement

Votre app est surtout du code des autres. Les attaquants le savent et ciblent les paquets que vous tirez — des vers qui se propagent dans npm, des paquets populaires détournés et la confusion de dépendances.

À faire : Épinglez les versions et commitez un lockfile. Ajoutez le scan de dépendances pour attraper les paquets connus comme vulnérables et les nouveaux paquets suspects. Méfiez-vous particulièrement de tout ce que l'IA a suggéré par son nom. (Voir tous les cas supply-chain →)

La checklist de sécurité minimale viable

Imprimez-la. Passez-la avant chaque lancement.

Aucun secret dans la source, le frontend ou l'historique git — tous chargés depuis l'env / un gestionnaire de secrets
Détection de secrets + protection de push activées ; tout secret exposé renouvelé
Chaque endpoint exige l'authentification et vérifie que la ressource appartient à l'appelant
Row-level security activée ; accès anonyme testé contre chaque endpoint
Défauts du framework utilisés pour le SQL (paramétré) et le HTML (auto-échappé) ; CSP en place
URL fournies par l'utilisateur validées (pas de SSRF) ; les uploads de fichiers ne peuvent pas s'exécuter
Dépendances épinglées, lockfilées, scannées ; existence des paquets suggérés par l'IA vérifiée
L'agent IA ne peut pas exécuter de commandes ni merger automatiquement ; chaque diff relu ; pas d'accès prod
Toute fonctionnalité LLM livrée traite l'entrée comme non fiable, nettoie la sortie, garde les secrets hors du prompt et fait approuver les actions réelles par un humain
Buckets/bases de données/panneaux d'admin privés par défaut ; rôles cloud au moindre privilège
Un vrai filtre de revue + analyse statique s'exécute avant que le code n'atteigne la production

Questions fréquentes

Le vibe coding est-il sécurisé ?

Le vibe coding n'est pas intrinsèquement non sécurisé, mais les agents de code IA produisent du code non sécurisé par défaut — des études ont trouvé qu'environ 45 % du code généré par IA contient une vulnérabilité de l'OWASP Top 10. Le risque le plus grand est le processus : le vibe coding retire la revue humaine, l'approbation du tech lead et les contrôles de sécurité qui attrapaient ces failles avant la production. Les apps vibe-codées peuvent être parfaitement sûres, mais seulement si le constructeur réintègre la revue, le scan et les pratiques de défaut sécurisé que l'équipe fournissait.

Quel est le plus grand risque de sécurité du vibe coding ?

Les deux erreurs les plus courantes et les plus dommageables sont les secrets en dur (clés API et identifiants commités dans le code, y compris le frontend) et le contrôle d'accès manquant (endpoints qui renvoient des données sans vérifier que le demandeur est autorisé pour cet enregistrement précis). Les deux ont causé d'énormes fuites bien réelles et sont livrées en routine par des agents IA qui optimisent pour du code qui marche, pas du code sûr.

Dois-je relire le code que mon agent IA écrit ?

Oui. En vibe coding, c'est vous la couche de revue — il n'y a ni ingénieur senior ni équipe sécurité derrière vous. Les agents IA émettent de façon fiable des vulnérabilités classiques comme l'injection SQL, le cross-site scripting et les secrets en dur, et ils peuvent aussi être détournés par des instructions cachées dans les fichiers qu'ils lisent. Lire chaque diff avant de l'accepter, plus passer un scanner de sécurité automatisé, est la pratique sûre minimale.

Comment garder les secrets hors de mon app vibe-codée ?

N'écrivez jamais de secrets sous forme de littéraux dans le code. Chargez-les depuis des variables d'environnement ou un gestionnaire de secrets à l'exécution, ajoutez les fichiers env et de clés au gitignore, et activez la détection de secrets en pre-commit plus la protection de push de votre hébergeur pour qu'une clé ne puisse pas atteindre le distant. Si un secret a un jour atteint un dépôt, renouvelez-le immédiatement — supprimer le commit ne l'enlève pas de l'historique git, et quiconque a cloné le dépôt l'a encore. Ne mettez jamais une vraie clé dans du code frontend ou mobile, car tout ce qui est livré au client est lisible par n'importe qui.

Puis-je faire confiance aux dépendances que mon assistant IA suggère ?

Non, pas sans vérifier. Les modèles de langage hallucinent des noms de paquets qui n'existent pas, et les attaquants pré-enregistrent ces noms hallucinés avec un malware — une classe d'attaque appelée slopsquatting. Vérifiez toujours qu'un paquet suggéré existe réellement et est légitime (téléchargements réels, mainteneur et historique de dépôt) avant de l'installer, épinglez les versions, commitez un lockfile et scannez les dépendances pour les problèmes connus.

Mon app utilise un chatbot ou un agent IA — à quoi dois-je faire attention ?

À l'injection de prompt. Le modèle ne peut pas distinguer vos instructions de l'entrée d'un attaquant, donc tout message utilisateur ou contenu ingéré (e-mail, document, lead CRM) peut le détourner. Ne concaténez jamais l'entrée utilisateur dans votre prompt système, ne mettez jamais de secrets dans le contexte du modèle, nettoyez et encodez la sortie du modèle avant de la rendre, limitez les outils et permissions de l'agent au minimum, et exigez une approbation humaine avant que l'agent n'entreprenne une action conséquente comme envoyer des données ou déplacer de l'argent.

L'essentiel

Le vibe coding a donné à des individus la production d'une équipe entière. Il ne leur a pas donné le jugement de l'équipe — le senior qui attrape la requête non paramétrée, le relecteur qui demande « est-ce authentifié ? », l'ingénieur sécurité qui bloque la clé en dur. C'est ce jugement qu'encode cette checklist, distillé de centaines de fuites réelles.

C'est aussi exactement pour cela que j'ai construit Stateward. C'est la couche de revue que l'équipe était : il analyse chaque pull request en ligne, vérifie chaque dépendance contre ce même flux de menaces d'attaques réelles, traque les secrets et les contrôles d'autorisation manquants qu'un agent laisse derrière lui, et vous dit ce qui est réellement exploitable — avant la livraison. Vibe-codez vite. Mais ne livrez pas à l'aveugle.