CSRF: cookies SameSite e tokens
Compreender como a falsificação de pedidos entre sites explora cookies, utilizar SameSite=Strict/Lax para a impedir e adicionar tokens sincronizadores para proteção adicional.
CSRF: cookies SameSite e tokens é uma aula grátis de Frontend Academy no CoddyKit. Esta é a aula 2 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Frontend Academy, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Frontend Academy inclui 4 aulas no total.
O que é CSRF?
Falsificação de solicitação entre sites: um atacante induz o navegador de um usuário autenticado a enviar uma solicitação ao seu site. O navegador anexa os cookies do usuário — o servidor considera que é uma solicitação legítima do usuário.
Ataque clássico de CSRF
O usuário está conectado a bank.com. Ele visita evil.com. evil.com envia um formulário oculto para bank.com/transfer com o número da conta do atacante. O navegador envia automaticamente o cookie de sessão de bank.com. O servidor transfere o dinheiro.
O problema da confiança
O CSRF funciona porque os navegadores incluem automaticamente os cookies em solicitações entre origens. Sem uma proteção adicional, o servidor não consegue saber que a solicitação veio de um site malicioso.
Cookies SameSite — a correção moderna
O atributo de cookie SameSite controla quando os cookies são enviados em solicitações entre origens. Strict: nunca é enviado entre origens. Lax (padrão no Chrome): é enviado somente em uma navegação GET de nível superior. None: é sempre enviado (também deve ser Secure).
Set-Cookie: session=abc; HttpOnly; Secure; SameSite=LaxPadrão SameSite=Lax
O Chrome define todos os cookies como Lax por padrão quando nenhum SameSite é especificado. Isso bloqueia a maioria dos ataques CSRF — mas você deve especificá-lo mesmo assim.
SameSite=Strict para máxima segurança
Use Strict para os cookies mais sensíveis (sessões de administradores, transações bancárias). A desvantagem é que o usuário parece desconectado ao chegar por meio de um link de outro site.
Tokens CSRF (padrão de sincronização)
Para oferecer suporte a navegadores antigos ou obter segurança adicional, use tokens CSRF. O servidor gera um token aleatório, incorpora-o à página e exige esse token em todas as solicitações que alteram o estado.
// Server embeds token in HTML or sets it as a non-HttpOnly cookie:
<meta name="csrf-token" content="a1b2c3...">
// Client reads token and sends in header:
const token = document.querySelector('meta[name=csrf-token]').content;
fetch('/transfer', {
method: 'POST',
headers: { 'X-CSRF-Token': token },
body: JSON.stringify({ amount: 100 })
});
// Server verifies the X-CSRF-Token header matches the user's sessionCookie de envio duplo
O servidor define um cookie CSRF (sem HttpOnly, para que JS possa lê-lo). O cliente o lê e envia o valor em um cabeçalho. O servidor verifica se o cookie corresponde ao cabeçalho. Um atacante não consegue ler o cookie entre origens, portanto não consegue reproduzir o cabeçalho.
Por que funciona
O evil.com do atacante não consegue ler os cookies de bank.com (política de mesma origem). Portanto, não consegue definir o cabeçalho X-CSRF-Token. A solicitação falha na verificação do token no servidor.
CSRF em SPAs com tokens Bearer
Se você autenticar com Authorization: Bearer <jwt> armazenado na memória (não em um cookie), o CSRF não se aplica — os navegadores não enviam cabeçalhos automaticamente. A desvantagem é uma maior vulnerabilidade a XSS, pois tokens acessíveis por JS podem ser roubados.
O truque do cabeçalho personalizado
Para APIs que aceitam apenas JSON com um cabeçalho personalizado (por exemplo, X-Requested-With), os navegadores enviam uma solicitação OPTIONS de verificação preliminar — e não incluem cookies nessa verificação. Isso bloqueia efetivamente o CSRF baseado em formulários simples.
Endpoints idempotentes vs. mutáveis
O CSRF afeta principalmente solicitações que alteram o estado (POST, PUT, DELETE). Os endpoints GET devem ser idempotentes — não produzir efeitos colaterais — para que um GET forjado não cause danos.
Verificação rápida
Qual valor do cookie SameSite impede, por padrão, que os cookies sejam enviados na maioria das solicitações entre sites nos navegadores modernos?
Recapitulação: prevenção de CSRF
Defina SameSite=Lax (ou Strict) nos cookies de sessão — isso bloqueia a maioria dos ataques CSRF. Adicione HttpOnly + Secure. Use tokens CSRF (de sincronização ou cookie de envio duplo) para obter proteção adicional. Tokens Bearer em cabeçalhos evitam CSRF, mas aumentam o risco de XSS. O truque do cabeçalho personalizado força uma verificação preliminar. Faça com que os GETs sejam idempotentes.
Perguntas Frequentes
A aula “CSRF: cookies SameSite e tokens” é grátis?
Sim — o texto completo de “CSRF: cookies SameSite e tokens” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Frontend Academy, atualize para CoddyKit PRO. O curso de Frontend Academy inclui 4 aulas no total.
O que vou aprender em “CSRF: cookies SameSite e tokens”?
Compreender como a falsificação de pedidos entre sites explora cookies, utilizar SameSite=Strict/Lax para a impedir e adicionar tokens sincronizadores para proteção adicional. Você pratica Frontend Academy com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar Frontend Academy?
Nenhuma experiência prévia é necessária. Frontend Academy no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 2 de 4.
Quanto tempo leva a aula “CSRF: cookies SameSite e tokens”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de Frontend Academy?
Sim. Cada aula de Frontend Academy inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Prevenção de XSS: codificação de saída e CSP
- CSRF: cookies SameSite e tokens
- Política de Segurança de Conteúdo: nonce e hash
- Fluxos OAuth no frontend