CSRF é quando simplesmente abrir outro site enquanto ainda está logado dispara uma transferência ou mudança de configuração sem você saber. Veja como ele funciona e como preveni-lo de forma confiável (sem passos de ataque).
Por que funciona (o mecanismo)
Um navegador anexa automaticamente os cookies de um site às requisições para aquele site. Então, se um usuário está logado no banco dele, uma requisição ao banco disparada a partir de uma página maliciosa ainda carrega "os cookies do usuário". Para o servidor, é indistinguível de uma ação legítima.
Enquanto o XSS "roda código no navegador da vítima", o CSRF "toma emprestado o estado logado da vítima" (→ O que é XSS).
Defesa
Exija um token CSRF
Em ações que mudam estado (envios de formulário, APIs), exija um token de uso único, inadivinhável, emitido pelo servidor; rejeite requisições sem ele. A maioria dos frameworks já entrega isso.
Defina cookies SameSite
Marque os cookies de sessão como SameSite=Lax (ou Strict) para que os cookies não sejam anexados a requisições originadas de outro site. Lax é o padrão moderno e ajuda muito por si só.
Não use GET para mudanças de estado
GET (visualização) não pode ter efeitos colaterais. Faça mudanças via POST/PUT/DELETE e passe-as pela validação de token.
Verifique Origin / Referer
Para ações sensíveis, verifique que a Origin da requisição é o seu próprio site e rejeite origens externas.
A visão deste site: na maior parte 'resolvido', mas não relaxe
Tokens CSRF de framework mais o padrão SameSite=Lax do navegador reduziram enormemente o CSRF clássico. Ainda assim, ele acontece em APIs customizadas, configurações legadas e painéis de administração que pularam o token. Mesmo que você "deixe a cargo do framework", verifique você mesmo uma vez que os caminhos que mudam estado de fato executam a validação de token.
Brechas comuns
Mesmo conhecendo o mecanismo, as implementações tendem a escorregar em dois pontos.
- GET com efeitos colaterais: se um GET de visualização muda estado, uma tag de imagem ou um link simples já bastam para CSRF. Faça mudanças de estado via POST/PUT/DELETE e passe-as pela validação de token.
- Esquecer a validação de token em alguns caminhos: APIs e recursos de administração adicionados depois costumam pular o token. Não presuma "o framework já tem" — inventarie todo caminho que muda estado uma vez.
CSRF vs XSS vs SSRF
Esses três nomes parecidos podem ser distinguidos por quem envia a requisição e do que se aproveitam.
| Ataque | Quem envia a requisição | Do que se aproveita | Defesa principal |
|---|---|---|---|
| CSRF | O navegador do usuário, sem que ele saiba | O navegador anexar cookies automaticamente | Tokens CSRF, cookies SameSite |
| XSS | O script do invasor rodando no navegador do usuário | Falta de escape quando a página é renderizada | Escape na saída, CSP |
| SSRF | O seu servidor | Um recurso que busca uma URL recebida | Allowlist de destinos, bloqueio de endereços internos |
CSRF e XSS agem ambos pelo navegador do usuário. Mas, se uma página tem XSS, um script dentro dela consegue ler o token CSRF, e as defesas contra CSRF são contornadas. A proteção contra CSRF pressupõe que o XSS já esteja resolvido.
Um caso real: uma publicação forjada tratada como sendo do próprio usuário
Em 2012, uma ameaça de ataque a escolas primárias foi publicada pelo formulário de opiniões do site da prefeitura de Yokohama, no Japão. O dono do PC de onde ela parecia ter vindo foi preso, e depois se descobriu que a prisão foi um erro.
Em dezembro daquele ano, segundo a imprensa japonesa, a polícia de Tóquio explicou que a publicação havia sido enviada usando CSRF: o navegador de um visitante foi levado a enviá-la depois que ele abriu um link publicado em um fórum.
Daí vêm duas lições.
- Uma requisição CSRF parece exatamente a do próprio usuário: o servidor vê apenas o endereço IP e os cookies do usuário. Só pelos logs não dá para saber se ele a enviou ou foi levado a enviá-la.
- Formulários sem login também entram na conta: aquele formulário de opiniões não exigia login. Coloque um token em todo envio que você não queira que terceiros disparem (publicações, inscrições, denúncias), exigindo login ou não.
O CSRF continua sendo uma fraqueza comum. No "CWE Top 25" da MITRE (as 25 fraquezas de software mais perigosas), publicado em dezembro de 2025, o CSRF (CWE-352) ficou em terceiro lugar.
Como verificar o seu próprio site
Defina SameSite explicitamente nos cookies de sessão
Verifique o atributo SameSite do cookie de sessão nas ferramentas de desenvolvedor do navegador (Application → Cookies) ou com a auditoria do site. Chrome e Edge tratam cookies sem o atributo como Lax, mas Safari e Firefox não fazem isso por padrão. Não dependa do padrão do navegador; defina você mesmo SameSite=Lax ou Strict.
Revise as exceções de CSRF
Verifique se a proteção contra CSRF do framework está desligada em algumas rotas (o csrf_exempt do Django, a lista de exceções do Laravel, o skip_forgery_protection do Rails etc.). Onde houver motivo para desligá-la, como um receptor de webhook, proteja a rota com verificação de assinatura.
Procure rotas GET que mudam estado
Percorra sua lista de rotas em busca de GETs que apagam, atualizam ou fazem logout. Passe-as para POST ou equivalente e coloque-as na validação de token.
Acrescente mais uma verificação às ações sensíveis
Para trocar senha ou e-mail, enviar dinheiro ou conceder permissões, peça a senha atual ou a autenticação multifator além do token. Mesmo que uma requisição seja forjada, a confirmação do usuário a detém.
Fontes (primárias)
- OWASP, "Cross-Site Request Forgery Prevention Cheat Sheet" (em inglês) — cheatsheetseries.owasp.org (tokens, Sec-Fetch-Site, limites do SameSite, XSS contornando as defesas contra CSRF, nada de mudança de estado via GET)
- MITRE, "2025 CWE Top 25 Most Dangerous Software Weaknesses" (dezembro de 2025, em inglês) — cwe.mitre.org (CWE-352 em terceiro lugar)
- web.dev, "SameSite cookies explained" (em inglês) — web.dev (quais navegadores tratam cookies sem o atributo como Lax)
- INTERNET Watch, reportagem sobre o caso do malware de controle remoto (14 de dezembro de 2012, em japonês) — internet.watch.impress.co.jp (explicação da polícia de que o CSRF foi usado na publicação de Yokohama)
- @IT, artigo sobre as prisões indevidas causadas por malware de personificação e CSRF (novembro de 2012, em japonês) — atmarkit.itmedia.co.jp
- IPA, "How to Secure Your Web Site" — ipa.go.jp (em japonês)
Leia a seguir
- Glossário: O que é XSS · O que é SSRF
- Fundamentos: Fundamentos de segurança