CSRF e cookies SameSite: o que mudou e o que ainda importa

CSRF (Cross-Site Request Forgery) é quando um site malicioso faz o navegador da vítima enviar uma requisição ao seu sistema usando a sessão dela — por exemplo, alterar o e-mail da conta sem ela saber. O atributo SameSite dos cookies reduziu muito esse risco, mas não eliminou.

O que o SameSite faz

• Strict: o cookie nunca é enviado em requisições vindas de outros sites.
• Lax (padrão atual dos navegadores): enviado apenas em navegações de topo com GET, como clicar num link.
• None: enviado sempre — exige Secure e reabre o risco.

O cookie de sessão ideal

Set-Cookie: sessao=...; HttpOnly; Secure; SameSite=Lax; Path=/

HttpOnly impede leitura por JavaScript (protege contra XSS — XSS em aplicações React: onde o React não te protege), Secure exige HTTPS.

Onde o risco continua

• Ações que mudam estado via GET: com Lax, um link pode disparar. Nunca altere dados com GET (API REST bem desenhada: nomes, status codes e paginação que não confundem ninguém).
• Cookies com `SameSite=None` para integrações entre domínios.
• Subdomínios comprometidos que compartilham cookies.
• Navegadores antigos.

Defesas adicionais

1. 1.Token anti-CSRF em formulários e requisições que alteram dados.
2. 2.Verificar `Origin` nas requisições sensíveis.
3. 3.Reautenticação para ações críticas (trocar senha, e-mail, dados bancários).

E se a API usa tokens no cabeçalho em vez de cookies, o risco de CSRF muda — mas surgem outros cuidados, discutidos em JWT: as armadilhas que deixam sua API aberta.

A We Codex revisa autenticação e sessões em Segurança Anti-Hacker. Fale com a gente.