Gerador de CSRF Token

O que é um token CSRF e por que sua aplicação precisa de um

CSRF — Cross-Site Request Forgery, também chamada de session riding ou XSRF — é a classe de ataque em que uma página maliciosa induz o navegador da vítima a disparar uma requisição autenticada contra um site terceiro em que ela já está logada. Como o navegador anexa automaticamente o cookie de sessão, o servidor-alvo vê uma requisição perfeitamente legítima e a executa: transfere dinheiro, troca o e-mail da conta, concede privilégios de admin. A prova de conceito clássica é uma tag de imagem apontando para um endpoint GET que muda estado, por exemplo <img src="https://banco.com/transferir?para=atacante&valor=1000">. Assim que a vítima visita a página do atacante, o GET dispara e o dinheiro sai.

Um token CSRF é uma string aleatória e imprevisível atrelada à sessão do usuário que o servidor exige em toda requisição que muda estado (POST, PUT, PATCH, DELETE). Como um atacante cross-origin não consegue ler o HTML nem os cookies da vítima, ele não consegue adivinhar o token e a requisição forjada é rejeitada. O token deve vir de um CSPRNG (gerador pseudoaleatório criptograficamente seguro) com pelo menos 128 bits de entropia — crypto.randomBytes(32) do Node, secrets.token_urlsafe(32) do Python ou crypto.getRandomValues() da Web Crypto são fontes adequadas.

Os três padrões canônicos de defesa

• Synchronizer Token Pattern — o servidor gera um token, guarda na sessão, embute como campo oculto em todo formulário e compara o valor enviado no POST. É o que o CsrfViewMiddleware do Django, o protect_from_forgery do Rails e o filtro CSRF do Spring implementam.
• Double Submit Cookie — o servidor seta o token como cookie comum (não HttpOnly) e o cliente espelha o valor em um header customizado como X-CSRF-Token. JavaScript do mesmo origem consegue ler o cookie; scripts cross-origin não, então a requisição forjada chega sem o header.
• Validação de Origin / Referer — alternativa barata usada por frameworks como segunda linha de defesa; rejeita qualquer requisição mutante cujo header Origin não bata com o host da aplicação.

Cookies SameSite e navegadores modernos

Desde o Chrome 80 (fev/2020) os cookies vêm por padrão com SameSite=Lax, o que bloqueia o envio em quase todo POST cross-site e mitiga automaticamente boa parte dos vetores de CSRF. Mas o SameSite=Lax ainda permite cookies em navegações GET top-level, e nem todo agente (navegadores antigos, webviews embutidas) impõe o mesmo default. Defesa em profundidade ainda exige tokens CSRF; o OWASP, a Mozilla e a própria RFC do SameSite afirmam que ele é uma mitigação, não substituto.

SPAs, APIs JSON e a questão do cookie

Se sua API autentica com Bearer token no localStorage, CSRF se torna estruturalmente impossível porque o navegador não anexa o header Authorization cross-origin — a troca é a exposição a XSS. Se você autentica com cookies de sessão HttpOnly (default mais seguro), você precisa de proteção CSRF. Padrão comum em SPA: o servidor seta um cookie XSRF-TOKEN no login, o cliente lê via JavaScript e devolve no header X-XSRF-TOKEN em toda chamada mutante. Axios, HttpClient do Angular e Laravel Sanctum já implementam essa convenção.

Perguntas frequentes

SameSite=Lax sozinho basta? Mitiga a maioria dos POSTs cross-site forjados, mas não protege contra ataques entre subdomínios do mesmo site, contra mutações via GET nem contra navegadores que ignoram o atributo. O OWASP recomenda combinar SameSite com tokens CSRF explícitos.

Preciso de CSRF numa API JSON pura? Apenas se a API é autenticada por cookies. Se ela usa Bearer token no header Authorization (estilo OAuth/JWT), o navegador não anexa a credencial cross-origin automaticamente e o CSRF deixa de existir.

Quanto tempo um token CSRF deve durar? Vincule à sessão — quando a sessão expira ou o usuário desloga, invalide o token. Tokens por formulário (one-shot) são mais fortes mas quebram comportamentos legítimos como botão voltar e abas concorrentes; tokens por sessão são o meio-termo usual.

Este gerador envia o token para algum servidor? Não. Os bytes vêm de crypto.getRandomValues() no seu navegador e não saem da aba. Gere, copie e cole no seu formulário, store de sessão ou fixture de teste.