What is insecure output handling in LLM apps, and how does it cause XSS or SSRF?
Short answer
Insecure output handling is trusting what the model returns and passing it to a downstream system without validation or encoding. Because model output is attacker-influenceable, rendering it as raw HTML causes XSS, feeding it to a URL fetcher causes SSRF, and passing it to a shell or SQL query causes command or SQL injection. The fix is to treat model output exactly like untrusted user input: context-aware output encoding, allowlisting, sanitization, and parameterization before it reaches any sink.
Insecure output handling (OWASP calls it improper output handling) is a classic appsec mistake wearing an AI hat: the application trusts what the model returns and passes it straight to a downstream component. The catch is that model output is attacker-influenceable — through direct prompts, jailbreaks, or indirect injection in retrieved data — so it must be treated as untrusted, the same as any user input.
How it turns into real vulnerabilities
The bug appears at the sink, wherever the output lands:
- XSS. The app renders the model's response as raw HTML/Markdown in a browser. If the model emits
<script>or anonerrorhandler (because an attacker coaxed it to), it executes in the victim's session. - SSRF. The app takes a URL from the model and fetches it server-side, letting an attacker reach internal services or cloud metadata endpoints.
- Command / SQL injection. Output is concatenated into a shell command or SQL query.
- Path traversal, open redirect, log injection — same pattern, different sink.
A subtle point: even if you sanitized the user's input, the model can synthesize a malicious payload on its own, so input sanitization alone doesn't protect the sink.
Defenses
Apply the same discipline as for any untrusted data:
- Context-aware output encoding before rendering (HTML, attribute, JS, URL contexts).
- Allowlist and validate structured output (URLs, IDs, enums) against strict schemas.
- Parameterize queries and avoid passing output to shells.
- Sandbox and egress-filter any server-side fetch or execution.
What interviewers look for
The framing that "model output is untrusted input," the ability to name the sink for each vulnerability (XSS, SSRF, command injection), and reaching for context-aware encoding and validation rather than blaming the prompt.
Likely follow-ups
- Why is model output an injection vector even if the user input was sanitized?
- What context-aware encoding would you apply before rendering model output in HTML?
- How does this risk compound when the output is fed to a tool-using agent?