Qu'est-ce que le traitement non sécurisé des sorties dans les applis LLM, et comment cause-t-il du XSS ou du SSRF ?

Le traitement non sécurisé des sorties (OWASP l'appelle improper output handling) est une erreur d'appsec classique déguisée en IA : l'application fait confiance à ce que le modèle renvoie et le transmet directement à un composant en aval. Le piège est que la sortie du modèle est influençable par l'attaquant — via des prompts directs, des jailbreaks ou de l'injection indirecte dans des données récupérées — elle doit donc être traitée comme non fiable, au même titre que toute entrée utilisateur.

Comment cela se transforme en vraies vulnérabilités

Le bug apparaît au sink, là où la sortie atterrit :

• XSS. L'application affiche la réponse du modèle en HTML/Markdown brut dans un navigateur. Si le modèle émet <script> ou un gestionnaire onerror (parce qu'un attaquant l'y a amené), cela s'exécute dans la session de la victime.
• SSRF. L'application prend une URL du modèle et la récupère côté serveur, permettant à un attaquant d'atteindre des services internes ou des endpoints de métadonnées cloud.
• Command / SQL injection. La sortie est concaténée dans une commande shell ou une requête SQL.
• Path traversal, open redirect, log injection — même schéma, sink différent.

Un point subtil : même si vous avez assaini l'entrée de l'utilisateur, le modèle peut synthétiser une charge malveillante de lui-même, donc l'assainissement de l'entrée seul ne protège pas le sink.

Défenses

Appliquez la même discipline que pour toute donnée non fiable :

• Encodage de sortie sensible au contexte avant l'affichage (contextes HTML, attribut, JS, URL).
• Allowlister et valider la sortie structurée (URL, identifiants, énumérations) selon des schémas stricts.
• Paramétrer les requêtes et éviter de passer la sortie à des shells.
• Sandboxer et filtrer la sortie réseau de toute récupération ou exécution côté serveur.

Ce que recherchent les recruteurs

Le cadrage « la sortie du modèle est une entrée non fiable », la capacité à nommer le sink de chaque vulnérabilité (XSS, SSRF, command injection), et le recours à l'encodage sensible au contexte et à la validation plutôt que de blâmer le prompt.