Proteção contra CSRF em configurações de React e API

Falsificação de Solicitação entre Sites (CSRF) é um ataque em que um site malicioso engana o navegador do usuário para que envie uma solicitação autenticada à sua API. Como o navegador anexa cookies automaticamente às solicitações, o servidor não consegue distinguir entre uma solicitação legítima da sua aplicação e uma solicitação falsificada do site do atacante.

Os cookies são a causa principal da vulnerabilidade a CSRF. Quando um usuário entra na sua aplicação, o cookie de sessão fica armazenado no navegador. Quando ele visita a página do atacante, o atacante pode iniciar o envio de um formulário ou uma solicitação fetch à sua API, e o navegador inclui automaticamente o cookie de sessão — autenticando a solicitação maliciosa.

O atributo de cookie SameSite informa aos navegadores quando incluir cookies em solicitações entre sites. Ele tem três valores: Lax (o padrão nos navegadores modernos — bloqueia POST entre sites, mas permite GET), Strict (bloqueia todas as solicitações entre sites, incluindo navegações GET) e None (permite solicitações entre sites, mas exige o sinalizador Secure do HTTPS).

SameSite=Lax bloqueia solicitações POST, PUT, DELETE e PATCH entre sites — os métodos usados para mutações. Se sua API usar GET somente para leituras e POST para todas as mutações, SameSite=Lax impedirá efetivamente CSRF em SPAs nos navegadores modernos. Essa é a medida de proteção básica adotada atualmente pela maioria das aplicações.

O padrão de Envio Duplo de Cookie é uma medida de proteção contra CSRF na qual o servidor define um token CSRF aleatório em um cookie que não é HttpOnly. O cliente lê o valor desse cookie e o inclui como um cabeçalho de solicitação personalizado (por exemplo, X-CSRF-Token). O servidor verifica se o valor do cabeçalho corresponde ao valor do cookie. Um atacante não consegue ler o cookie de uma origem diferente e, portanto, não consegue definir o cabeçalho correto.

O Padrão de Token de Sincronização gera um token CSRF exclusivo para cada sessão de usuário no servidor. Em formulários HTML, o token é inserido em um campo oculto. Para chamadas de API de uma SPA, o token é fornecido por um ponto de acesso ou por uma tag meta e enviado em um cabeçalho personalizado. O servidor valida o token em cada solicitação que altera o estado.

Uma SPA React que armazena seu JWT na memória ou em localStorage e o envia em um cabeçalho Authorization: Bearer não é vulnerável ao CSRF clássico. Os ataques CSRF exploram a autenticação baseada em cookies — a página de um atacante não pode definir cabeçalhos personalizados em solicitações entre origens devido às restrições do CORS e, portanto, não pode falsificar o cabeçalho de autorização.

Solicitações simples entre origens (envio de formulário POST ou carregamento de imagem) não permitem cabeçalhos personalizados. Somente solicitações que passam pela pré-verificação do CORS podem incluir cabeçalhos personalizados — e solicitações pré-verificadas exigem permissão explícita do servidor. Uma API que exige um cabeçalho personalizado (como X-Requested-With: XMLHttpRequest) para todas as mutações fica protegida por natureza contra ataques CSRF simples.

CORS controla quais origens podem ler a resposta de uma solicitação entre origens. CSRF diz respeito a quais origens podem fazer solicitações que alteram o estado. Configurar CORS para restringir origens não impede CSRF — o navegador ainda envia a solicitação e o cookie; CORS controla apenas se a resposta fica visível para o JavaScript. Um ataque CSRF não precisa ler a resposta.

Configure os cookies de sessão com: HttpOnly: true (impede que o JavaScript leia o cookie, bloqueando o roubo de tokens baseado em XSS), Secure: true (enviado somente por HTTPS), SameSite: Lax ou Strict (impede CSRF) e um Max-Age ou prazo de expiração adequado. Esses quatro atributos, juntos, fortalecem significativamente o gerenciamento de sessões.

O App Router do Next.js usa ações do servidor, que são solicitações POST. O Next.js implementa proteção contra CSRF verificando o cabeçalho Origin em relação ao host — solicitações de origens inesperadas são rejeitadas. Essa verificação integrada, combinada com cookies de sessão SameSite=Lax, oferece proteção sólida contra CSRF para mutações baseadas em ações do servidor.

Qual valor do cookie SameSite bloqueia solicitações POST entre sites, mas permite navegações GET entre sites?

CSRF explora a autenticação baseada em cookies ao induzir o navegador a enviar solicitações autenticadas entre sites. SameSite=Lax é a defesa básica nos navegadores modernos. Os padrões de cookie de envio duplo e token sincronizador oferecem proteção adicional. SPAs React que usam JWT em cabeçalhos de autorização são inerentemente resistentes a CSRF. Cabeçalhos personalizados obrigatórios e a verificação preliminar de CORS também reduzem o risco de CSRF. Sempre combine HttpOnly + Secure + SameSite nos cookies de sessão.