Vibe coding avec l’IA : rapide, brillant… et troué
ump — Un mot de passe pourri backfill 2025-12-23 · Voir sur Substack ↗
Les LLM codent en 10 secondes ce qui prenait 2h. Mais ils optimisent le "ça marche", pas le "c'est sûr". SSRF, injections, deps fantômes : la prod hérite du proto sans le savoir. Mode d'emploi réel ici : https://unmotdepassepourri.substack.com/p/vibe-coding-avec-lia-rapide-brillant
1/ Les assistants IA produisent du code probable, pas du code sûr. Ils génèrent le pattern le plus fréquent dans leurs données d'entraînement : souvent un tuto, rarement un code audité.
2/ Trois angles morts structurels : → Pas de modèle de menace (exposition Internet ? données sensibles ?) → Pas de contraintes réglementaires (RGPD, NIS2) → Pas de contexte infra (proxy, egress filtering, quotas)
3/ Premier piège : SSRF. Le LLM pond requests.get(user_url) sans filtre. Résultat : accès IMDS, localhost, réseau interne si l'app consomme une URL utilisateur côté serveur.
4/ Le patch minimal : allowlist de domaines + vérif IP publique + disable redirects + timeout. Bonus infra : egress filtering, sandbox, logs d'accès. Sinon, un attaquant pivot vers vos services internes.
5/ Deuxième piège : injection shell. os.system(f"whois {domain}") → faille directe. Solution : subprocess.run avec liste d'args, jamais de f-string dans un shell. Règle générale : API/bindings paramétrés partout (SQL, CLI, LDAP, OS).
6/ Troisième piège : dépendances hallucinées. Le LLM invente des packages, typosquatte, ou ajoute des deps non maintenues. Contre-mesure : requirements.txt + hashes, pip-audit en CI, revue humaine des noms.
7/ Le vibe coding accélère. Mais confondre "ça compile" avec "c'est déployable" glisse des failles en prod. Vitesse + garde-fous = gains réels. Détails, patterns et code durci : https://unmotdepassepourri.substack.com/p/vibe-coding-avec-lia-rapide-brillant
Les LLM codent comme des stagiaires brillants : ils pondent du fonctionnel en 10 secondes, ignorent ton exposition Internet et laissent un requests.get(user_url) ouvert sur ton IMDS. La prod hérite du proto. L'incident suit.
Le code "le plus probable" n'est pas le code le plus sûr. Les LLM optimisent la vraisemblance statistique, pas ta surface d'attaque. Si tu valides en mode "ça marche", tu shippes les failles des tutos StackOverflow en prod.
On a remplacé les devs juniors par des LLM qui codent comme des devs juniors. Même biais : le fonctionnel immédiat prime, la sécu attendra. Sauf qu'avec l'IA, on ship 10× plus vite… et on hérite de 10× plus de SSRF.