Glossário
O que é CSRF (Cross-Site Request Forgery) — fazer um usuário logado agir sem querer
O CSRF (Cross-Site Request Forgery) usa o navegador de um usuário logado para enviar uma requisição que ele nunca pretendeu, como uma transferência. Como funciona e a defesa de verdade: tokens CSRF, cookies SameSite e verificação de Origin.
"Só de abrir outro site enquanto ainda está logado, uma transferência ou mudança de configuração é disparada sem você saber" — isso é CSRF. 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 morde 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.
Leia a seguir
- Glossário: O que é XSS · O que é SSRF
- Fundamentos: Fundamentos de segurança
FAQ
QQual é a diferença entre CSRF e XSS?
O XSS roda um script no navegador da vítima; o CSRF usa o estado logado da vítima para enviar uma requisição não intencional. O CSRF funciona até sem rodar nenhum script — apenas com o navegador enviando cookies automaticamente.
QQual é a principal defesa contra CSRF?
Exija um token CSRF em requisições que mudam estado (POST, etc.) e defina SameSite (Lax/Strict) nos cookies de sessão. A maioria dos frameworks já entrega o token por padrão. Além disso: nunca use GET para mudanças de estado.
QSameSite sozinho é suficiente?
Ajuda muito, mas não é bala de prata. Restam brechas em navegadores antigos, em certas navegações e em algumas configurações de subdomínio — então combine-o com tokens CSRF para defesa em profundidade.