XSS é quando um texto digitado em um formulário roda como script na tela de outra pessoa. 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 é a falha mais grave do lado do servidor, o XSS é a mais grave do lado do cliente (usuário).
Defesa: 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 que um XSS passe, o dano é menor.
A visão deste site: a melhor defesa é não desabilitar você mesmo os recursos de segurança
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 comprovado, e não pelo seu próprio tratamento de strings. "Desabilitar a segurança por conveniência" é o maior risco.
Como o XSS difere de ataques com que é confundido
O XSS costuma ser confundido com o CSRF, que tem nome parecido, e com a injeção de SQL, que também é um caso de entrada tratada como instrução. A diferença está no que roda e onde.
| Ataque | O que acontece, e onde | Defesa principal |
|---|---|---|
| XSS | O script do invasor roda no navegador do usuário como parte da página real | Escape na saída, CSP |
| CSRF | A sessão logada do usuário é usada para enviar uma requisição que ele não pretendia. Nenhum script precisa rodar | Tokens CSRF, cookies SameSite |
| Injeção de SQL | A entrada é interpretada no servidor como parte de uma instrução SQL | Placeholders |
| Clickjacking | A página real é sobreposta de forma invisível para que o usuário clique nela sem saber | CSP frame-ancestors |
Note que o XSS também derruba as defesas contra CSRF. Quando um script roda dentro da página, ele consegue ler também o token CSRF daquela página (o guia de CSRF da OWASP faz o mesmo alerta).
Um caso real: XSS em uma tela aberta pela equipe
Em 2026, a Instructure, empresa por trás do sistema de gestão de aprendizagem Canvas, informou que uma invasão começou com XSS. Segundo a empresa, o invasor usou uma conta gratuita para enviar um chamado de suporte com código malicioso e, quando um atendente o abriu, uma falha de XSS foi explorada para obter privilégios elevados dentro do Canvas (→ o vazamento de dados do Canvas (Instructure)).
A lição é que o XSS não é um problema só de páginas públicas. Telas de suporte, de contato e de administração que mostram à sua equipe textos enviados de fora têm risco maior, porque as contas que as abrem têm mais poder.
O XSS continua entre as fraquezas mais comuns. No "CWE Top 25" da MITRE (as 25 fraquezas de software mais perigosas), publicado em dezembro de 2025, o XSS (CWE-79) ficou em primeiro lugar. Em setembro de 2024, as agências americanas CISA e FBI também publicaram um alerta pedindo que os fabricantes de software eliminem o XSS de seus produtos.
Como verificar o seu próprio site
Você não precisa testar strings de ataque. Comece por estas quatro verificações.
Encontre os pontos que inserem HTML cru
Procure no seu código por dangerouslySetInnerHTML, v-html, innerHTML e document.write, e verifique se algum valor fornecido pelo usuário pode chegar até eles. Se puder, renderize-o como texto ou passe-o por um sanitizador comprovado.
Verifique se a CSP é enviada
Use a Verificação de cabeçalhos de segurança para ver se a Content-Security-Policy está presente e o que ela permite. Permitir 'unsafe-inline' a enfraquece muito contra XSS. Para escrever uma nova, faça o rascunho com o Gerador de CSP e rode-a primeiro em modo Report-Only (que apenas relata violações).
Verifique as flags do cookie de sessão
Nas ferramentas de desenvolvedor do navegador (Application → Cookies), confirme que o cookie de sessão tem HttpOnly e Secure. A auditoria do site também verifica as flags dos cookies.
Inclua as telas de administração e suporte
Verifique se as telas internas que mostram textos vindos de fora (corpo de chamados, nomes de arquivo, nomes de exibição) fazem o escape com o mesmo padrão das páginas públicas.
Fontes (primárias)
- OWASP, "Cross Site Scripting Prevention Cheat Sheet" (em inglês) — cheatsheetseries.owasp.org (escape por contexto de saída, padrões seguros dos frameworks)
- MITRE, "2025 CWE Top 25 Most Dangerous Software Weaknesses" (dezembro de 2025, em inglês) — cwe.mitre.org (CWE-79 em primeiro lugar)
- CISA e FBI, "Secure by Design Alert: Eliminating Cross-Site Scripting Vulnerabilities" (17 de setembro de 2024, em inglês) — cisa.gov
- OWASP, "Cross-Site Request Forgery Prevention Cheat Sheet" (em inglês) — cheatsheetseries.owasp.org (o XSS pode contornar as defesas contra CSRF)
- IPA, "How to Secure Your Web Site" — ipa.go.jp (em japonês)
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
- Defesa em profundidade: cabeçalhos de segurança não são uma lista para empilhar (a CSP limita o que um XSS consegue fazer)