XSS vs CSRF: diferenças chave, exemplos e como prevenir ambos

XSS vs CSRF: a diferença de relance

Qual é a diferença entre XSS e CSRF? O XSS faz o site vulnerável executar o script do atacante no navegador da vítima, com acesso total à página. O CSRF faz o navegador da vítima enviar uma requisição ao site vulnerável a partir de uma página controlada pelo atacante, abusando do fato de que os cookies vão junto automaticamente. O XSS pode ler e agir; o CSRF só pode agir.

O que é XSS (cross-site scripting)?

O cross-site scripting acontece quando uma aplicação coloca a entrada do usuário em uma página sem codificá-la: o navegador então interpreta essa entrada como HTML ou JavaScript em vez de exibi-la como texto. O script injetado roda sob a origem do site, com acesso à página, ao seu DOM, aos seus cookies não-HttpOnly e a tudo o que o usuário pode fazer.

Ele vem em três variantes, detalhadas no nosso guia de cross-site scripting:

• XSS refletido: a carga viaja na requisição (em geral um parâmetro de URL) e é devolvida na resposta. A vítima precisa abrir um link malicioso.
• XSS armazenado: a carga é salva (um comentário, uma bio) e servida a todo visitante. Sem link para enviar, o que o torna o tipo mais perigoso.
• XSS baseado em DOM: o JavaScript do próprio site escreve um dado não confiável, como location.hash, na página. O servidor às vezes nunca vê a carga.

Um exemplo de ataque XSS

Uma página de busca devolve a consulta sem codificá-la:

<!-- PHP vulnerável -->
<p>Resultados para: <?php echo $_GET['q']; ?></p>

Envie q=tenis e a página mostra "Resultados para: tenis". Envie q=<script>alert(document.domain)</script> e o navegador interpreta isso como uma tag script real e a executa. A prova é um alerta inofensivo, mas o mesmo ponto de apoio permite que um script leia a página e envie requisições em nome do usuário logado. Se o cookie de sessão não estiver marcado como HttpOnly, ele também pode lê-lo diretamente, e é por isso que esse único atributo importa tanto.

O que é CSRF (cross-site request forgery)?

O cross-site request forgery faz o navegador de um usuário logado enviar uma requisição sensível a um site que confia nele. A página do atacante monta a requisição, o navegador anexa os cookies da vítima, e o servidor vê uma sessão válida e executa a ordem. Nada é injetado no site vulnerável.

Como funciona um ataque CSRF

1. A vítima faz login em bank.example. Um cookie de sessão é guardado no navegador dela.
2. Ela abre a página do atacante em outra aba, ainda logada.
3. Essa página dispara uma requisição para bank.example, escondida numa tag de imagem ou num formulário autoenviado.
4. O navegador anexa o cookie de sessão automaticamente, pois é assim que os cookies funcionam para qualquer requisição àquele domínio.
5. O servidor a trata como legítima, sem conseguir distinguir uma requisição forjada de uma real.

Um exemplo de ataque CSRF

Para um endpoint que aceita GET, uma tag de imagem oculta na página do atacante já basta:

<!-- Na página do atacante -->
<img src="https://bank.example/transfer?to=mallory&amount=1000" style="display:none">

Para um endpoint POST, um formulário autoenviado faz o mesmo trabalho:

<form action="https://bank.example/transfer" method="POST" id="f">
  <input type="hidden" name="to" value="mallory">
  <input type="hidden" name="amount" value="1000">
</form>
<script>document.getElementById('f').submit();</script>

Como XSS e CSRF diferem por dentro

O XSS pode levar ao CSRF?

Sim, e é por isso que o XSS é mais grave que o CSRF. Um token CSRF funciona porque a página externa do atacante não consegue lê-lo. Mas o XSS roda dentro da origem: o script injetado pode então ler o token direto da página e anexá-lo a uma requisição forjada. A requisição então parece perfeitamente legítima, token incluído.

Em outras palavras, um ponto de apoio de XSS atravessa as defesas de CSRF sem esforço. A conclusão prática: se um site tem XSS, você tem o CSRF de graça, mais a leitura dos dados. Corrigir o CSRF não faz nada contra o XSS, e um XSS não corrigido mina suas proteções de CSRF.

Como prevenir XSS e CSRF

Os dois exigem defesas diferentes. Tokens CSRF não fazem nada contra o XSS, e a codificação de saída não faz nada contra o CSRF. Você quer os dois conjuntos no lugar.

Prevenindo XSS

• 🔒 Codificação de saída conforme o contexto. Faça escape do dado do usuário para o contexto exato onde ele cai (corpo HTML, atributo, JavaScript, URL). Esse é o conserto que acaba com a falha. Deixe o framework fazer escape por padrão e audite cada escape hatch como dangerouslySetInnerHTML ou um innerHTML cru.
• 🛡️ Content Security Policy. Uma CSP estrita que bloqueia scripts inline é uma sólida segunda camada. Ela não conserta a falha, mas pode impedir uma carga de executar quando uma escapa.
• 🍪 Cookies de sessão HttpOnly. Impedem o JavaScript de ler o cookie de sessão, neutralizando a forma mais direta de roubo de sessão. Combine com Secure.
• ✅ Sanitize HTML rico com uma biblioteca testada. Se os usuários enviam HTML legitimamente, passe-o pelo DOMPurify em vez de um filtro caseiro.

Prevenindo CSRF

• 🎫 Tokens anti-CSRF. Coloque um token imprevisível por sessão em cada formulário sensível e verifique-o no servidor. Uma página externa não consegue lê-lo nem adivinhá-lo.
• 🍪 Cookies SameSite. SameSite=Lax (padrão do Chrome desde 2020) impede os cookies de irem na maioria das requisições cross-site; Strict é mais apertado. Trate como defesa em profundidade, não como único controle, pois é um comportamento do navegador, não uma verificação do servidor.
• 🔍 Verificações de Fetch Metadata e Origin. Rejeite requisições sensíveis cujo cabeçalho Sec-Fetch-Site ou Origin mostre que vieram de outro site.
• 🔐 Reautenticação para ações críticas. Exija senha ou uma etapa de confirmação para operações sensíveis como transferências.

Impacto no mundo real

Os dois ataques voltam sempre porque a confiança que eles abusam, um navegador confiando no conteúdo e um servidor confiando em um cookie, está inscrita no funcionamento da web. Veja o ranking atual no OWASP Top 10:2025.

Como testar XSS e CSRF

Pratique com labs dedicados

Considerações legais e éticas

• Teste apenas em sistemas seus, em alvos de treino propositalmente vulneráveis, ou dentro do escopo autorizado de um bug bounty ou contrato.
• Use provas inofensivas. Não implante cargas que leiam dados de usuários reais para demonstrar impacto.
• Se encontrar uma falha na aplicação de outra pessoa, reporte pelo processo de divulgação dela e pare por aí.
• Os labs e cursos ligados aqui existem para praticar legalmente tanto o ataque quanto a defesa.