Cybersecurity glossary
What is Insecure Output Handling?
Learn what insecure output handling is, how unsanitized LLM completions become XSS, command injection, or fraud, and how to treat model output as untrusted user input in every downstream system.
Definition
Insecure output handling is the failure to treat LLM completions as untrusted data. When applications render, execute, or forward model output without encoding, validation, or policy checks, attackers who influence the prompt can reach browsers, shells, SQL, emails, or workflows.
Why insecure output handling matters
Teams obsess over what users type into a chatbot and then paste the model’s reply into a page as HTML, into a shell as a command, or into an agent as a function call. Insecure output handling is that last mile: the completion is just a string from an untrusted interpreter.
Prompt injection without a dangerous sink is often a content issue. The same injection plus a Markdown renderer, eval, or unrestricted HTTP client is a classic web or RCE bug with an LLM as the decoder ring.
How unsafe output reaches a sink
Influence the completion
Direct or indirect injection shapes what the model emits.
Skip validation
The app assumes JSON, Markdown, or SQL from the model is well-formed and benign.
Choose a powerful sink
Browser DOM, template engine, database, shell, email, or workflow engine consumes the string.
Interpret as code or markup
HTML is executed, queries run, or links are fetched with the victim’s session.
Impact the user or backend
XSS, data theft, unauthorized actions, or malware delivery follow.
Repeat through automation
Agents that chain completions into the next tool call amplify one bad string.
High-risk sinks for model text
Rich chat UIs
Markdown-to-HTML, Mermaid, and ‘clickable citations’ are XSS and tracking-pixel territory.
Code interpreters
‘Run this’ features that execute model-written Python or JS without a sandbox.
Query builders
Natural-language-to-SQL that concatenates identifiers or predicates from the model.
Outbound messages
Completions copied into email, Slack, or CSV can carry links, macros, or prompt payloads.
Encode for the destination
| Destination | Treat completion as | Control |
|---|---|---|
| HTML / Markdown UI | Untrusted markup | Sanitize or render as text; CSP; no raw HTML from the model |
| SQL / query APIs | Untrusted identifiers and values | Parameterized queries; allowlisted tables; no string concat |
| Shell / notebooks | Untrusted code | Sandbox, no secrets in the runtime, network egress off by default |
| HTTP / tools | Untrusted URLs and args | Allowlists, SSRF controls, schema validation |
| Email / tickets | Untrusted user content | Link rewriting, formula escaping, no auto-run macros |
- Classify every sink that consumes model output the same way you classify sinks for user input.
- Never pass completions to innerHTML, eval, exec, or unsanitized templates.
- Validate structured output against a schema; reject extra fields and unexpected types.
- Disable arbitrary HTML in assistant messages; prefer plain text or a tight Markdown subset.
- Sandbox any code interpreter: no cloud credentials, no production network, tight CPU/memory.
- Apply SSRF and URL allowlists to model-proposed fetches.
- Add XSS and injection tests that use the model as the payload generator, not only static strings.
- Remember second-order paths: tickets, logs, and notifications that re-display completions.
The practical takeaway
Insecure output handling is trusting an LLM completion as if a senior engineer typed it. The model is an untrusted user who is good at syntax.
Encode for HTML, parameterize queries, sandbox execution, and validate tool arguments. If injection can change the text, unsafe handling is what turns that text into a breach.
Related security terms
Prompt Injection
The usual way attackers shape the completion that is then handled unsafely.
Cross-Site Scripting (XSS)
A common result of rendering model Markdown or HTML without encoding.
Code Injection
Risk when completions are executed as code or queries.
Excessive Agency
When unsafe handling includes executing tool calls the model proposed.
Guardrail
Output validation and encoding that should sit after generation.
Frequently asked questions
What is insecure output handling in simple terms?
The model’s answer is treated as trusted HTML, SQL, shell, or JSON. If an attacker influenced that answer, they inherit whatever the application does with it.
Is this the same as prompt injection?
Prompt injection is how the attacker steers the model. Insecure output handling is how the application turns that steered text into a real exploit in a browser, database, or agent runtime.
Why is Markdown a problem?
Many UIs convert model Markdown to HTML. A completion that includes a script, a javascript: link, or a tracking image becomes XSS or data exfiltration when rendered.
Can JSON mode make output safe?
Structured output helps parsing, not trust. The model can still put a payload in a string field that a later eval(), template, or URL fetch will honor.
What about copying answers into tickets or emails?
Forwarding unsanitized completions can inject formulas, links, or instructions into other systems. That is second-order output handling.
Does OWASP use a different name?
The LLM Top 10 lists this as Improper Output Handling (LLM05). Insecure output handling is the same idea in engineering language.
How do you handle output safely?
Encode for the destination, validate against schemas, never eval, sandbox code execution, and apply the same XSS and injection controls you use for user content.
References
Explore authoritative guidance and frameworks related to insecure output handling.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.