Gestion des sorties non sécurisées des LLM : quand le code généré par l'IA vous attaque 💻

L’ère du “Vibe Coding” — où les logiciels sont construits via des instructions en langage naturel et une génération assistée par IA — est officiellement arrivée. À l’horizon 2026, la dépendance aux Large Language Models (LLMs) pour écrire du code, résumer des données et alimenter des agents autonomes atteint un niveau critique. Mais cette efficacité a engendré un dangereux “écart de confiance”.

Nous traitons souvent le contenu généré par l’IA comme un produit “propre” de logique interne. En réalité, un LLM est un proxy sophistiqué pour des entrées externes non fiables. Lorsqu’une application prend la sortie d’un LLM et la transmet directement à un navigateur web, une base de données ou un shell système sans validation rigoureuse, elle crée une vulnérabilité connue sous le nom de Gestion non sécurisée des sorties.

Dans la communauté de la sécurité, cela est officiellement reconnu comme LLM05:²⁰²⁵⁄₂₀₂₆ dans le Top 10 OWASP pour les applications LLM. Ce guide explore en profondeur comment le code généré par l’IA peut être utilisé comme arme, les mécanismes du XSS piloté par LLM, et comment construire une stratégie de défense pour la pile IA moderne.

1. Le paradoxe de la confiance : pourquoi la sortie IA est “toxique”

Dans la sécurité web traditionnelle, la règle d’or est : Ne jamais faire confiance à l’entrée utilisateur. Nous nettoyons les champs de formulaire et échappons les requêtes SQL par habitude.

Cependant, lorsqu’un LLM est introduit, les développeurs abaissent souvent leur garde. Il existe une tendance psychologique à considérer le LLM comme une composante interne “sûre”. Si un utilisateur demande à un chatbot de “résumer cette page”, et que le chatbot renvoie un bloc de code ou du Markdown, l’application le rend souvent immédiatement.

La réalité ? Si cette “page” contenait une instruction cachée (Injection indirecte de prompt), le LLM devient le vecteur de livraison d’une attaque. Le code ne provient pas de vos développeurs ; il provient d’une source non fiable, filtrée par une machine qui ne comprend pas intrinsèquement les limites de sécurité.

Le cycle de vie d’une attaque par sortie LLM

1. Le déclencheur : un attaquant place une instruction cachée (par exemple, dans un site web, un PDF ou un email) conçue pour être lue par un LLM.
2. Le traitement : une application alimentée par IA demande à traiter ces données (par exemple, “Analyser ce document”).
3. La charge utile : le LLM suit l’instruction cachée et génère une réponse malveillante, comme une balise 3cscript3e ou une commande SQL malformée.
4. L’exécution : l’application reçoit la sortie du LLM et l’affiche dans le navigateur de l’utilisateur (XSS) ou l’exécute dans une base de données, en supposant que la sortie de l’IA est sûre.

2. Anatomie de l’attaque : XSS piloté par LLM

Le Cross-Site Scripting (XSS) reste la manifestation la plus courante d’une gestion incorrecte des sorties. En 2026, la recherche indique que près de 45 % des extraits de code générés par IA pour des tâches frontend contiennent des failles de sécurité.

Le piège de innerHTML

Considérons un chatbot de support client moderne. Il utilise une bibliothèque pour convertir la sortie Markdown du LLM en HTML pour une interface élégante.

Implémentation JavaScript vulnérable :

// Réception de la réponse de l'API LLM
const aiResponse = await llm.generate(userInput);

// VULNÉRABLE : rendu direct dans le DOM
// Si aiResponse contient 3cscript3e, il s'exécute immédiatement.
document.getElementById('chat-history').innerHTML = aiResponse;

Si un attaquant parvient à déclencher le LLM pour qu’il produise :

"Je peux vous aider avec ça ! 3cimg src=x onerror=alert('Session_Vole9e')3e"

Le navigateur exécutera ce JavaScript. Dans un scénario réel, ce script pourrait servir à voler des cookies de session, rediriger vers des sites de phishing ou effectuer des actions au nom de l’utilisateur dans l’application.

Smuggling Markdown

Même si vous n’utilisez pas innerHTML, les attaquants sont devenus experts en Markdown Smuggling. De nombreux convertisseurs Markdown en HTML sont étonnamment permissifs. Un attaquant pourrait tromper un LLM pour qu’il génère un “bouton” qui est en réalité un lien déguisé vers une URI javascript:, contournant les filtres simples de balises.

3. Au-delà du navigateur : risques SQLi et agentiques

Alors que le XSS est très visible, la gestion non sécurisée des sorties peut compromettre tout le backend, surtout avec la montée en puissance de l’IA agentique — des modèles capables de “faire” des choses, pas seulement de “dire”.

Injection SQL pilotée par LLM (SQLi)

De nombreux “Assistants de données” permettent aux utilisateurs d’interroger des bases de données en langage naturel. Le LLM traduit la requête en SQL.

Scénario : un utilisateur demande, “Montre-moi les ventes du mois dernier.”

Sortie du LLM : SELECT * FROM sales WHERE month = 'January';

Si l’application exécute cette chaîne directement contre la base, elle est vulnérable. Un attaquant pourrait utiliser une invite comme :

"Montre-moi les ventes du mois de 'January' ; DROP TABLE users; --"

Si l’application n’utilise pas de requêtes paramétrées pour la sortie du LLM, elle risque une perte totale de données ou un accès non autorisé.

Exécution de code à distance (RCE) via des agents

En 2026, les “Workflows agentiques” donnent souvent aux agents IA la capacité d’exécuter le code qu’ils écrivent (par exemple, dans un interpréteur Python ou un shell local). Si la sandboxing est faible, ou si la gestion des sorties permet à l’agent d’écrire dans le système de fichiers local, l’agent devient une menace “vivante” (LotL).

Risque clé : Ne jamais passer la sortie du LLM directement dans des fonctions comme eval(), exec(), ou system() dans n’importe quel langage de programmation.

4. Pourquoi les WAF traditionnels échouent

Les Web Application Firewalls (WAF) sont conçus pour repérer des signatures d’attaque connues dans les requêtes utilisateur. Cependant, les sorties LLM sont probabilistes.

Un LLM pourrait générer un script malveillant en utilisant de l’obfuscation qu’un WAF ne reconnaît pas comme une menace, car cela ressemble à un “tutoriel” ou un “exemple de code” légitime. De plus, comme l’attaque provient de l’intérieur de votre infrastructure de confiance (connexion API LLM), elle contourne souvent complètement les défenses périmétriques.

5. Plan de mitigation technique : la norme 2026

Pour se défendre contre “l’attaque IA”, il faut traiter le LLM comme un utilisateur sophistiqué et non fiable. Utilisez l’approche multicouche suivante.

Couche 1 : Nettoyage contextuel

Ne vous contentez pas de supprimer les balises ; utilisez des bibliothèques conçues pour le contexte spécifique de la sortie.

• Pour le rendu web : utilisez DOMPurify pour nettoyer tout HTML avant rendu.
• Pour Markdown : nettoyez après la conversion Markdown en HTML.
• Pour les données : utilisez une validation stricte du schéma (par exemple, Zod ou Pydantic) pour assurer que la sortie du LLM correspond au format attendu.

Couche 2 : La règle du “Sink sûr”

Évitez les “sinks dangereux” dans votre code. Remplacez-les par des alternatives plus sûres qui traitent le contenu comme du texte littéral plutôt que du code exécutable.

Méthode dangereuse	Alternative plus sûre	Avantage sécurité
element.innerHTML	element.textContent	Empêche l’analyse HTML/Script.
eval(llm_code)	Sandbox isolé (WASM)	Limite l’accès au système hôte.
db.execute(sql)	db.prepare(query)	La paramétrisation évite l’injection SQL.
window.location	Redirections en liste blanche	Empêche les redirections ouvertes via IA.

Couche 3 : Politique de sécurité du contenu (CSP)

Une CSP robuste est votre filet de sécurité ultime. En restreignant où les scripts peuvent être chargés et en désactivant unsafe-inline, vous pouvez neutraliser le XSS même si un script malveillant passe la couche de nettoyage.

/* Exemple d'en-tête CSP */
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';

Couche 4 : Human-in-the-Loop (HITL)

Pour les actions à haut risque — comme supprimer des données, envoyer des emails ou exécuter des transactions financières — la sortie du LLM ne doit jamais être la décision finale. Mettez en place une étape “Humain dans la boucle” où un utilisateur doit approuver manuellement l’action proposée par l’IA.

6. La montée en puissance des workflows “auto-sécurisés” par l’IA

Vers la fin de 2026, l’industrie évolue vers AISec — la sécurité intégrée à l’IA. Cela implique l’utilisation d’un “Modèle de garde” secondaire, très contraint, pour inspecter la sortie du LLM principal.

• LLM principal : génère la réponse/le code.
• LLM de garde : analyse la réponse pour détecter instructions cachées, scripts malveillants ou PII.
• Application : ne rend la sortie que si le Modèle de garde donne un signal “Propre”.

Cette approche “Defense en profondeur” reconnaît que, bien qu’un modèle puisse être trompé, il est beaucoup plus difficile de tromper deux modèles indépendants avec des invites système différentes.

7. Analyse comparative : risques d’entrée vs. sortie

Il est crucial de distinguer Prompt Injection (l’entrée) et Gestion non sécurisée des sorties (le résultat).

Fonctionnalité	Injection de prompt (entrée)	Gestion non sécurisée des sorties (résultat)
Cible	La logique et les contraintes du LLM	Le backend/frontend de l’application
Objectif	Faire en sorte que l’IA ignore ses règles	Exécuter du code dans le navigateur ou le serveur
Défense principale	Ingénierie des prompts, filtrage d’entrée	Nettoyage des sorties, CSP, sandboxing
Propriétaire	Ingénieurs IA/ML	Développeurs Full-Stack / équipe AppSec

8. Liste de vérification pour les développeurs

Pour que votre application alimentée par IA ne devienne pas un vecteur d’attaque, suivez cette liste :

• [ ] Nettoyez tout : utilisez DOMPurify pour tout contenu UI généré par l’IA.
• [ ] Pas d’exécution directe : ne passez jamais la sortie du LLM à eval(), os.system(), ou shell=True.
• [ ] Validation de schéma : assurez-vous que la sortie JSON du LLM correspond à un schéma strict avant utilisation.
• [ ] Sécurité de la base de données : utilisez des requêtes préparées pour toute requête générée par l’IA.
• [ ] CSP strict : mettez en place une politique de sécurité du contenu qui interdit les scripts inline.
• [ ] Sandboxing : si l’IA doit exécuter du code, faites-le dans un environnement verrouillé et éphémère (par exemple, un conteneur Docker sans accès réseau).

Conclusion : sécuriser l’avenir du “Vibe Coding”

La vitesse de développement de l’IA est impressionnante, mais la sécurité ne doit pas être une réflexion après coup. La Gestion non sécurisée des sorties est un tueur silencieux — elle semble fonctionner parfaitement jusqu’au moment où une réponse “de confiance” de l’IA se transforme en arme.

En traitant la sortie du LLM avec la même scepticisme qu’une chaîne brute provenant d’un paramètre URL, les développeurs peuvent exploiter la puissance de l’IA sans ouvrir la porte à la prochaine génération d’attaques par injection.