Pourquoi le vibe coding crée des trous de sécurité
Le vibe coding, c'est génial pour une chose : arriver vite à un produit qui marche. Tu décris ce que tu veux, l'IA le code, ça tourne. Vraie valeur, aucun débat.
Le piège, c'est de confondre "ça marche à l'écran" et "c'est prêt pour la vraie vie". L'IA t'écrit du code qui fonctionne. Pas du code qui résiste. La différence, c'est tout ce qui ne se voit pas dans la démo : qu'est-ce qui se passe quand quelqu'un essaie d'entrer par effraction, de tester mille mots de passe, de trafiquer une requête ?
Ces réflexes-là, l'IA ne les a pas. Pas parce qu'elle est mauvaise, mais parce que personne ne les lui demande. La sécurité, ça ne casse pas la démo, donc ça passe à la trappe.
J'audite régulièrement des apps vibe codées. Et je retrouve presque toujours la même liste de trous. Les voici, classés du plus fréquent au plus subtil. Pour chacun : ce que c'est, pourquoi l'IA passe à côté, et comment vérifier si ton app est concernée, même sans être technique.
1. Des secrets écrits en clair dans le code
Le risque. Un mot de passe, une clé d'accès à un service, un jeton d'API... écrits noir sur blanc dans les fichiers du projet. Le pire cas que je vois souvent : le mot de passe du compte administrateur, celui qui peut tout faire, planqué dans le code. Et comme le code garde un historique de toutes ses versions, même si tu l'effaces aujourd'hui, il reste lisible dans le passé du projet.
Pourquoi l'IA passe à côté. Pour qu'une démo marche, il faut bien que le mot de passe soit quelque part. Le plus simple pour l'IA, c'est de l'écrire directement. Ça marche. C'est juste que "ça marche" et "c'est sûr", ce n'est pas pareil.
Comment vérifier. Demande à qui code pour toi (ou à l'IA elle-même) : "est-ce qu'il y a des mots de passe, des clés ou des secrets écrits directement dans le code ?" La bonne réponse, c'est qu'ils doivent tous vivre dans des variables d'environnement, un endroit séparé du code. Règle simple : si c'est dans le code, considère que c'est public.
2. Un login sans limite de tentatives
Le risque. Rien n'empêche un attaquant de tester des mots de passe à l'infini, à pleine vitesse. C'est comme une porte blindée dont on peut essayer les codes un par un, autant de fois qu'on veut, sans que personne ne s'en aperçoive. Avec des outils automatiques, des milliers d'essais par minute, c'est juste une question de temps.
Pourquoi l'IA passe à côté. Un formulaire de connexion qui marche, c'est "je tape mon mot de passe, ça me laisse entrer". L'IA fait ça parfaitement. L'idée de compter les échecs et de bloquer au bout de quelques tentatives, c'est une couche en plus que personne ne réclame.
Comment vérifier. "Qu'est-ce qui se passe si quelqu'un se trompe de mot de passe dix fois de suite ? Cinquante fois ?" Si la réponse est "rien, il peut continuer", tu as le trou. Il faut un blocage après quelques échecs, et idéalement un ralentissement.
3. Des dépendances jamais mises à jour
Le risque. Une app moderne, c'est ton code plus des dizaines de briques toutes faites, écrites par d'autres. Ces briques ont parfois des failles. Quand une faille est découverte, elle est publiée publiquement, pour que tout le monde puisse se mettre à jour. Le problème : les attaquants lisent ces publications aussi. Une faille connue et non corrigée, c'est une porte ouverte avec le mode d'emploi affiché à côté.
Pourquoi l'IA passe à côté. L'IA installe ces briques à un instant T et passe à autre chose. Elle ne revient jamais vérifier si une mise à jour de sécurité est sortie depuis. Et toi non plus, si personne ne te dit que c'est un truc à faire.
Comment vérifier. "Quand est-ce que les dépendances de l'app ont été mises à jour pour la dernière fois ?" Si la réponse est "à la création, jamais depuis", c'est à traiter. C'est une vérification rapide, qui se fait avec des outils gratuits et automatiques.
4. Le serveur qui fait confiance au client
Le risque. C'est le plus important, et le plus technique, alors prenons une image. Ton app, c'est deux parties : ce qui tourne sur l'écran de l'utilisateur (le "client"), et ce qui tourne sur ton serveur. Tout ce qui est sur l'écran de l'utilisateur, il peut le modifier. Donc si ton serveur fait confiance à ce que lui envoie l'écran sans revérifier, n'importe qui peut lui mentir.
Exemple concret : l'app demande au serveur "donne-moi le document numéro 42". Si le serveur le donne sans vérifier que ce document appartient bien à la personne qui le demande, il suffit de demander le 43, le 44, le 45... et de lire les données des autres.
Pourquoi l'IA passe à côté. Quand l'IA code, elle fait communiquer l'écran et le serveur dans le même élan. Le réflexe "ne jamais croire ce que dit le client, toujours revérifier côté serveur" demande une vraie discipline de méfiance. L'IA, par défaut, fait confiance.
Comment vérifier. C'est le plus dur à tester sans regarder le code. Pose la question franchement : "est-ce que le serveur revérifie systématiquement que chaque utilisateur a le droit d'accéder à ce qu'il demande, ou est-ce qu'il fait confiance à ce que l'écran lui envoie ?" C'est typiquement le genre de chose qu'un audit traque en premier.
5. Les jetons de session mal rangés
Le risque. Quand tu te connectes, le serveur te donne une sorte de bracelet d'accès (un "jeton") qui prouve que c'est bien toi, pour ne pas te redemander ton mot de passe à chaque clic. La question, c'est où ce bracelet est rangé dans le navigateur. S'il est rangé dans un endroit accessible au code de la page, une autre faille (voir le point 6) permet de le voler. Et avec ton bracelet, l'attaquant devient toi, sans jamais avoir eu ton mot de passe.
Pourquoi l'IA passe à côté. La façon la plus simple de stocker ce jeton est aussi la moins sûre. L'IA prend le chemin le plus court : ça marche, l'utilisateur reste connecté. Le rangement sécurisé demande une config un peu plus fine.
Comment vérifier. "Où est stocké le jeton de connexion, et est-ce qu'il est accessible au code qui tourne dans la page ?" La bonne pratique, c'est un rangement que le code de la page ne peut pas lire directement.
6. Les entrées utilisateur prises telles quelles
Le risque. Tout ce qu'un utilisateur peut taper (un nom, un commentaire, un message) peut contenir, au lieu de texte, des instructions cachées. Si ton app réaffiche ce contenu sans le neutraliser, ces instructions peuvent s'exécuter chez les autres visiteurs. C'est le grand classique qui permet, entre autres, de voler les jetons du point 5. Même chose pour les exports : un fichier tableur peut cacher des formules piégées.
Pourquoi l'IA passe à côté. Afficher ce que l'utilisateur a tapé, c'est la fonctionnalité de base. Le neutraliser avant de l'afficher, c'est une étape invisible que rien ne réclame dans la démo.
Comment vérifier. "Est-ce que tout ce que les utilisateurs saisissent est nettoyé avant d'être réaffiché à d'autres ?" C'est une protection standard, souvent fournie par les outils modernes, mais qu'on peut contourner sans le vouloir.
7. La config de production laissée par défaut
Le risque. Le code peut être impeccable, mais déployé avec une config de prod négligente. Les classiques : le mode "debug" resté activé (il affiche des détails techniques précieux pour un attaquant en cas d'erreur), des messages d'erreur qui en disent trop, ou l'app qui tourne avec les pleins pouvoirs sur le serveur (du coup, si elle est compromise, l'attaquant sort direct sur toute la machine au lieu de rester coincé dans l'app).
Pourquoi l'IA passe à côté. La config de déploiement, ce n'est pas du code applicatif. C'est l'environnement autour. L'IA génère l'app, rarement la façon propre de la mettre en ligne. Et le mode debug, justement, est super pratique pendant le développement, donc il reste souvent allumé par oubli.
Comment vérifier. "Est-ce que le mode debug est éteint en production ? Est-ce que les messages d'erreur affichés aux utilisateurs restent vagues ? Est-ce que l'app tourne avec le minimum de droits sur le serveur ?"
La bonne nouvelle : aucun de ces trous n'est grave à fermer
Si tu lis cette liste et que tu sens monter l'angoisse, respire. Voilà ce que j'observe à chaque audit : ces trous sont des oublis, pas des défauts de conception. Des cases jamais cochées parce que personne ne savait qu'elles existaient. Pas une app à réécrire.
La plupart se ferment en quelques heures à quelques jours, pas en semaines. Sortir un secret du code : dix minutes. Bloquer les tentatives de login : une demi-journée. Mettre à jour les dépendances : une demi-journée. Le plus dur, le point 4, demande une vraie relecture, mais reste largement rattrapable.
Et le vrai message, c'est celui-ci : si le cœur de ton app a été bien construit (et le code généré à l'IA l'est souvent plus qu'on ne le croit), ces trous sont la couche de finition. Pas les fondations. On les bouche, et tu passes de "ça marche" à "c'est solide".
Tu veux savoir lesquels de ces trous sont dans ton app ?
Cette liste te donne de quoi poser les bonnes questions. Mais pour savoir vraiment ce qui se cache dans ton code, il faut le lire. C'est ce que je fais : je passe ton app au crible, je te liste les vrais risques classés par gravité, et je te donne un plan de correction priorisé, du "à faire aujourd'hui" au "ça peut attendre". Découvre l'offre Audit.
Et si tu veux ce genre de check-list directement dans ta boîte mail, inscris-toi à la newsletter. Un mail de temps en temps, que du concret, zéro spam.
