Insecure Output Handling.

OWASP LLM02 — passing LLM-generated output directly into downstream systems (browsers, shells, SQL, code execution) without validation, turning a hallucination or prompt injection into XSS, RCE, or SSRF. Cette notion relève de la catégorie Sécurité de l'IA et du ML en cybersécurité.

OWASP LLM02 — passing LLM-generated output directly into downstream systems (browsers, shells, SQL, code execution) without validation, turning a hallucination or prompt injection into XSS, RCE, or SSRF.

Insecure Output Handling is item LLM02 in the OWASP Top 10 for LLM Applications. It captures a deceptively simple mistake: treating model output as trusted text. When an application renders LLM responses in HTML, evaluates them as JavaScript, concatenates them into shell commands, executes them as code, or stuffs them into SQL, an attacker who can influence the prompt (directly or indirectly via retrieved content) controls whatever downstream sink consumes that output. The model becomes a confused-deputy that crosses trust boundaries on behalf of the attacker. Mitigations are conventional appsec hygiene applied to the LLM's egress: escape, sanitize, or template all output before HTML rendering; refuse to execute model-generated code outside a sandbox; validate structured outputs (e.g. JSON Schema, function-call argument types) before dispatch; require explicit allowlists for tools that take string arguments; and treat the LLM as an untrusted parser of intent, not a trusted producer of code.

Les défenses contre Insecure Output Handling combinent habituellement des contrôles techniques et des pratiques opérationnelles, comme détaillé dans la définition ci-dessus.

Noms alternatifs courants : LLM02, Unsanitized LLM output.