Glossário
O que é XSS (Cross-Site Scripting) — código rodando no navegador de outra pessoa
XSS (Cross-Site Scripting) faz o script de um invasor rodar no navegador de outro usuário, levando a roubo de sessão e adulteração de página. Os três tipos (armazenado/refletido/DOM), como funciona e a defesa real (escape na saída, auto-escape do framework, CSP) — explicado de forma defensiva, sem passos de ataque.
"O texto que digitei em um formulário roda como um script na tela de outra pessoa" — isso é XSS. Veja como funciona e como evitá-lo de forma confiável (sem passos de ataque).
Os três tipos
O XSS se divide por "como a string maliciosa chega à execução".
| Tipo | Como é plantado |
|---|---|
| Armazenado | Salvo em um post/perfil e roda para todos que o visualizam (o mais perigoso) |
| Refletido | Um parâmetro da URL é refletido de volta direto na página; roda para quem clicar no link |
| Baseado em DOM | Sem ida e volta ao servidor — o JS do lado do cliente trata a entrada de forma insegura |
Por que é perigoso (como funciona)
O navegador roda qualquer <script> na página como "código legítimo". Se a string de um invasor cai como HTML na página, o navegador não consegue distingui-la do código real.
O dano é "tudo o que aquela página pode fazer". Se o RCE é o pior do lado do servidor, o XSS é o pior do lado do cliente (usuário).
Defesa: a correção real é "escape na saída"
O XSS é prevenido na saída, não na entrada. No momento em que você renderiza um valor, converta-o para que não possa ser interpretado como HTML.
Escape na saída (o mais importante)
Ao renderizar valores fornecidos pelo usuário, converta < > & " ' em entidades HTML — usando o método certo para o contexto (corpo HTML, atributo, JS, URL).
Não desabilite o auto-escape do seu framework
React/Vue/templates fazem auto-escape por padrão. Apenas evite a injeção de HTML cru (dangerouslySetInnerHTML, v-html) e você previne a maior parte do XSS.
Defesa em profundidade com CSP
A Content-Security-Policy permite que o navegador bloqueie scripts que você não autorizou, limitando o dano mesmo que algo passe.
Proteja os cookies
Marque os cookies de sessão como HttpOnly para que o JS não possa lê-los. Mesmo se roubados, o raio de impacto é menor.
A visão deste site: a melhor defesa é não abrir o buraco você mesmo
Frameworks modernos vêm seguros por padrão. A maior parte do XSS aparece no momento em que um desenvolvedor desabilita deliberadamente o auto-escape para "injetar HTML cru". Se você realmente precisa permitir HTML, passe-o por um sanitizador testado em batalha, e não pelo seu próprio tratamento de strings. "Desabilitar a segurança por conveniência" é o maior risco.
Leia a seguir
- Glossário: O que é CSRF · O que é RCE · O que é um JWT (um token frequentemente roubado via XSS)
- Fundamentos: Fundamentos de segurança
FAQ
QO que acontece com o XSS?
O script de um invasor roda no navegador da vítima como parte da página real. Isso pode significar roubo de sessão (login personificado), leitura de entradas, desfiguração da página ou execução automática de outras ações.
QQual é a principal defesa contra XSS?
Escape na saída: ao renderizar valores fornecidos pelo usuário, converta-os para que não sejam interpretados como HTML. Templates de React/Vue fazem isso por padrão, então a maior vitória é não desabilitar esse auto-escape (evite dangerouslySetInnerHTML, etc.). Adicione CSP para defesa em profundidade.
QSanitizar na entrada é suficiente?
Normalmente não. A correção real é escapar por contexto de saída (corpo HTML, atributo, JS, URL). Filtros de entrada sozinhos vazam por incompatibilidade de contexto. Apenas quando você precisa permitir HTML, passe-o por um sanitizador confiável.