The previous article in this series ended on a warning: a prompt injection at the input becomes dangerous only when something downstream trusts what the model hands back. This article takes that warning apart. Insecure output handling is the vulnerability that appears when an application forwards a model’s response to another component without validating, encoding, or sanitizing it first. The model generated the text, so the application treats it as safe, and that assumption is where the exploit lives.
OWASP catalogs this as its own entry, listed as LLM02 in the 2023 Top 10 for LLM Applications and carried forward as Improper Output Handling in the 2025 revision. It sits next to prompt injection for a reason. Injection is how an attacker reaches the model; insecure output handling is how the model reaches everything else.
THE MISSING TRUST BOUNDARY
Every security architecture draws lines between zones of trust. Data crossing from a lower-trust zone to a higher-trust one has to be checked at the border. A web server does not run whatever a browser sends it, and a database does not execute whatever a form field contains. These borders are where validation happens.
A language model sits inside the trusted zone of most applications, because developers built it and write its prompts. Its output then flows to browsers, shells, database drivers, and other services as if it carried the same trust as the surrounding code. But the model’s input shapes its output, and that input includes text from users, web pages, and documents the application does not control. The output therefore carries attacker influence while wearing the badge of a trusted internal component.
The correct mental model reverses the instinctive one. Model output is not a return value from a function the developer wrote. It is untrusted input from an outside source, and it deserves the same suspicion the application already gives a URL parameter or an uploaded file. Skipping that check is like a mailroom waving through a package because it came from an internal desk, never noticing an outsider slipped it onto that desk an hour earlier.
WHEN OUTPUT BECOMES AN EXPLOIT
The specific harm depends entirely on where the unchecked output lands. The same response is harmless in a plain text log and dangerous in an HTML page.
CROSS-SITE SCRIPTING
The most common case is a chat interface that renders the model’s reply as HTML. If the response contains a script tag or an event handler and the front end inserts it into the page without encoding, the browser runs it. An attacker who can steer the model’s output, through a crafted question or through poisoned content the model retrieved, can plant JavaScript that executes in the victim’s session.
This is ordinary stored or reflected cross-site scripting, except the payload rides through the model instead of a comment field. The browser cannot tell the difference, because there is none. It clears the script the same way a bank clears a check because a teller passed it along, never checking whether the check was genuine.
SERVER-SIDE REQUEST FORGERY
Agentic systems let the model produce URLs that the application then fetches. Suppose the model returns an address pointing at an internal service or a cloud metadata endpoint, and the application requests it without checking. The model has now become a proxy for reaching machines the attacker could never reach directly.
The application makes the request from inside the network perimeter, so the internal target answers. The model acts like a courier who will carry any envelope out to a locked room because a visitor in the lobby asked politely.
REMOTE CODE EXECUTION
The most severe case is an application that runs model output as code. Some assistants generate a snippet and pass it straight to an interpreter, a shell, or an evaluation function to produce a result. If an attacker influenced the generated command, executing it hands that attacker a shell. Handing an interpreter attacker-shaped text works the same way as giving a stranger the keys and asking no questions.
The pattern also appears when code concatenates model output into a SQL query, producing model-driven SQL injection, or into a template that a rendering engine evaluates.
HOW IT COMPOUNDS INJECTION
Insecure output handling rarely acts alone. It is the second half of a chain that begins with prompt injection. An indirect injection plants an instruction inside a web page, the model reads it and produces the attacker’s chosen output, and insecure output handling delivers that output to a sink that acts on it. The two flaws fit together like a key and a lock: injection cuts the key, and the missing output check leaves the lock open.
That is why the two OWASP entries belong together. Closing the output boundary does not stop injection, but it caps the damage. A fully subverted model whose output the application treats as untrusted text still cannot reach a shell or a browser to turn its subversion into an action. The barrier at the output is often the last one standing after every earlier defense has failed.
CONTAINING IT
The defenses are the same disciplines that contain any untrusted input, applied at a boundary developers do not instinctively see as one. The unifying rule is short: treat every model response as untrusted until proven otherwise. The controls stack like gates on a road, each stopping what the one before it let through.
Context-aware output encoding handles the rendering cases. The application HTML-encodes output bound for a page, URL-encodes output bound for a link, and escapes output bound for a shell. Encoding neutralizes the payload at the exact point where something would otherwise interpret it, the same way a web framework escapes user content before it reaches a template. The encoding must match the destination, because an escape that is correct for HTML is useless for a shell.
Validation against a strict schema handles the structured cases. When the application expects a number, an enum value, or a known set of fields, it parses the response, checks it against that shape, and rejects anything that does not fit rather than passing free-form text to the next stage. A response that should be a category label has no business containing a URL or a command.
Least privilege handles what encoding and validation miss. Model output bound for a database goes through parameterized queries, so the driver can never read it as SQL. A model-supplied URL gets fetched only if an allowlist permits it, and generated code runs in a sandbox with no path to production systems.
Each control assumes the output might be hostile and limits what a hostile output can touch. A summarizer that cannot open a network socket cannot be talked into server-side request forgery, whatever it emits.
WHAT TO TAKE AWAY
Insecure output handling is a failure of perspective more than a failure of code. The application treats the model as part of itself, when the model is really a channel through which outside text flows. Every standard defense against untrusted input already exists; the work is to recognize the model’s output as untrusted input and apply those defenses at that boundary.
The rule that follows is the one the prompt injection article pointed toward: assume the model can be made to say anything, and build so that whatever it says still has to pass a border check before it can act. The next article in the series moves to a different failure entirely, the training data and model supply chain that shape what the model becomes before it ever produces a single token.
T.
References
- OWASP Top 10 for LLM Applications - The official OWASP project page cataloging Insecure Output Handling and the broader LLM Top 10 referenced throughout this article.
- OWASP LLM05:2025 Improper Output Handling - The 2025 revision’s detailed entry defining the vulnerability, its downstream impacts, and prevention strategies.
- OWASP Cross Site Scripting (XSS) - The foundational reference for the XSS mechanism that model output reproduces when rendered without encoding.
- OWASP Server Side Request Forgery - Background on the SSRF class of attack that arises when an application fetches a model-supplied URL without validation.
- OWASP Output Encoding Cheat Sheet - Practical guidance on context-aware output encoding, the primary mitigation for the rendering cases described here.
