Home / Knowledge hub / Insecure output handling
Knowledge hub
Insecure output handling
Trusting what a model writes and passing it on to code or a browser unchecked.
What it means
Insecure output handling is what happens when an application takes text from an AI model and uses it without checking it first. The text might be placed on a web page, put into a database query, run as a command, or used as a link. The model's reply is treated as safe when it is not.
OWASP listed it as LLM02 in earlier editions of its list for large language model applications, and calls it improper output handling in the 2025 edition. The idea is simple: model output is untrusted input to whatever receives it. It works the same way whether the receiver is a browser, a database or an operating system.
Why it matters
A model can be steered by what it reads, as in indirect prompt injection. If its reply goes straight into a page, an attacker's script can run in your customer's browser, which is cross-site scripting with a model in the middle.
The same path can reach back-end systems. Output placed into a query can become SQL injection. Output passed to a shell can become command execution. Each is an old, well-understood flaw, now reachable by a route the team did not think of as an input.
How it shows up
You meet it in chat widgets that render the model's reply as HTML or markdown, in assistants that generate code or queries and run them, in tools that follow links the model produced, and in pipelines where one model's output feeds another system.
The fixes are the usual ones, applied to the model's text. Encode output for the place it lands. Use parameterised queries. Never pass it to a shell. Validate structured replies against a schema and reject what does not fit. Keep the model's tools to a short, fixed list. Then test with inputs that make the model produce script tags and quotes.
Questions people ask
Insecure output handling, answered
Is insecure output handling the same as prompt injection?
No. Prompt injection is how bad instructions reach the model. Insecure output handling is what your app does with the reply afterwards.
One feeds the other, but fixing the second protects you even when the first happens.
Can we trust output from our own model?
Treat it like input from a user. The model can be steered by data it read, and it can simply be wrong.
Check and encode it before it reaches anything that acts on it.
Does rendering markdown from a model cause problems?
It can. Links and images in markdown can send data to an outside address, and some renderers allow raw HTML.
Sanitise the result, limit which domains images and links may point to, and avoid raw HTML.
How do we test for it?
Ask the assistant, or feed it content, that makes it output script tags, quotes, template syntax and shell characters, then see where the text lands and whether it is encoded.
Follow the reply through each system it touches.
What is the one-line fix?
Apply the same output encoding and parameterisation you would for user input, at every place the model's text is used.
Never give the model a direct route to a shell or a raw query.
Sources
Where this comes from
Related
Terms that sit next to this one
XSS
An attacker's script running in your pages, in your customers' sessions.
Output encoding
Escaping data for its destination so it is shown as text, not run as code.
SQL injection
Input a database ends up running as part of a query.
Command injection
Input that ends up run as an operating system command on your server.
OWASP LLM Top 10
The OWASP list of the main security risks in applications built on language models.
Where does the model's text land?
We follow input and output through your running app, including features built on a model, and prove what lands unchecked with the request, the response and a screenshot where a person can see it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.