O risco começa depois da geração

Imagine um assistente que escreve descrições para um catálogo. A equipe confere se o texto faz sentido, mas entrega a resposta diretamente ao navegador como HTML. A qualidade da redação não comprova que esse conteúdo pode ser executado ou incorporado com segurança.

A OWASP trata o processamento inadequado de saídas de modelos como uma categoria própria de risco, LLM05:2025. O problema surge quando sistemas seguintes recebem respostas sem o tratamento necessário. A saída do modelo deve atravessar uma fronteira de validação antes de chegar à interface ou a outro componente. [1]

Primeiro, escolha o que a tela realmente precisa

Se o produto precisa de texto, exiba texto. Se precisa de títulos, listas e links, defina esses elementos de forma explícita. Pedir “gere HTML seguro” não substitui uma política implementada na aplicação.

Em React, a documentação alerta que dangerouslySetInnerHTML insere HTML bruto e pode introduzir XSS quando recebe conteúdo não confiável. Ter usado um modelo conhecido não transforma a resposta em uma origem confiável. [2]

Três decisões para o time de produto

  1. Qual formatação é necessária? Comece com o menor conjunto que resolve a tarefa. Um resumo pode funcionar com parágrafos e listas, sem HTML arbitrário.

  2. Quais destinos podem aparecer? Links precisam de regras próprias; escapar texto não equivale a validar o destino de uma URL.

  3. O que acontece quando a resposta falha? Prepare uma apresentação em texto simples ou uma mensagem clara, em vez de tentar “consertar” qualquer conteúdo silenciosamente.

A OWASP diferencia codificação de saída, sanitização de HTML e validação de URLs. A defesa depende do contexto em que o navegador interpretará o dado. Uma política de segurança de conteúdo, CSP, é uma camada adicional, não substitui o tratamento correto. [3]

Aplicação prática: revisar uma tela em uma tarde

Proposta de exercício, não relato de resultado: escolha uma tela que mostre respostas de IA e desenhe o caminho entre a resposta recebida e o componente visual. Marque onde há transformação para HTML e onde surgem links ou incorporações.

Depois, escreva exemplos de entrada e o comportamento esperado: texto com sinais de menor e maior; link fora da política; resposta malformada; formatação não suportada; mensagem longa; retorno vazio. Execute os casos em ambiente de teste, usando dados sintéticos. Confira tanto a apresentação quanto a ausência de ações inesperadas.

Registre um responsável pelo contrato de apresentação. Quando o renderizador, suas dependências ou o formato de resposta mudar, execute novamente os mesmos casos. Inclua um caminho de fallback que preserve a informação útil sem habilitar recursos desnecessários.

A decisão que vale levar para a próxima revisão

Antes de discutir se a resposta parece boa, pergunte: “O que nossa aplicação permite que esse conteúdo faça?”. A confiança na interface deve vir de regras verificáveis no software, não da aparência convincente do texto.

Fontes

[1] OWASP — LLM05:2025 Improper Output Handling: https://genai.owasp.org/llmrisk/llm052025-improper-output-handling/

[2] React — Common components, dangerouslySetInnerHTML: https://react.dev/reference/react-dom/components/common#dangerously-setting-the-inner-html

[3] OWASP — Cross Site Scripting Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Referências consultadas em 17/10/2026. Conteúdo técnico de aplicação prática; não anuncia um lançamento ocorrido nesta data.