Como impedir Cross Site Request Forgery em 2026

Cross site request forgery é o ataque em que um site malicioso envia uma requisição autenticada ao seu banco ou aplicativo usando os cookies já guardados no navegador da vítima. O servidor vê uma sessão válida e executa a ação sem suspeitar de nada. A boa notícia: SameSite, tokens CSRF e verificação de origem resolvem a maior parte do problema.

O que é cross site request forgery?

Cross site request forgery (CSRF) é o ataque em que um site malicioso convence o navegador da vítima a disparar uma requisição autenticada contra outro site, aproveitando cookies que o navegador anexa automaticamente. O servidor valida o cookie, acredita que o usuário autorizou a ação e executa o pedido. A vulnerabilidade não quebra a autenticação; ela a usa contra você.

O cenário clássico funciona assim: você faz login num banco que usa cookies de sessão. Depois abre um site de golpes com um formulário escondido. Ao clicar, o formulário envia um POST para a rota do banco, e o navegador inclui o cookie de sessão no pacote. Para o servidor, a requisição é indistinguível de um clique seu.

Esse nome aparece em muitas grafias, e a página de referência da OWASP sobre CSRF documenta o ataque e suas mitigações. Vale lembrar que navegadores e frameworks modernos já bloqueiam a maior parte desses casos por padrão, mas entender o mecanismo evita que você desmonte essa proteção sem perceber.

Como o ataque funciona na prática?

Na demonstração do vídeo de julho de 2026 do canal do Augusto Galego, o ataque aparece em um ambiente controlado com dois servidores locais. O banco fake roda em localhost:3000 e o site do golpe em localhost:4000. A vítima faz login no banco, troca de aba para o site de prêmios e clica em um botão.

Na aba Network do navegador, aparece o registro do clique: um POST disparado pelo site do prêmio contra a rota /account/delete do banco. O servidor respondeu com status 200, ou seja, a conta foi deletada. O motivo do sucesso está nos cookies do navegador, que ainda carregavam a sessão válida do banco.

Esse tipo de requisição pode vir de um formulário submetido automaticamente por JavaScript, sem clique nenhum. O HTML do site atacante não precisa ler nada do banco; ele só precisa conhecer a rota e contar com o cookie sendo anexado. É uma simulação feita para a aula, não um teste em sistema real, e o resultado ilustra bem a mecânica do golpe.

Como o atributo SameSite bloqueia o ataque?

O atributo SameSite, documentado pela MDN, diz ao navegador quando um cookie pode viajar em requisições entre sites diferentes. Com SameSite=Lax, o cookie só vai em requisições de navegação no mesmo site, o que já barra o formulário do golpe. Com SameSite=Strict, o cookie nem acompanha um clique em link vindo de outro domínio; ele só volta depois do primeiro request dentro do site.

Na prática, Lax é o padrão em navegadores modernos justamente para conter CSRF sem quebrar logins vindos de links externos. Strict é mais seguro, mas custa usabilidade: se você clica num link do Google para o banco, chega sem sessão e precisa de um novo request para ser reconhecido.

Esse é o primeiro degrau de defesa porque não exige código no servidor. Você só configura o cookie na hora de emitir a sessão e o navegador cuida do resto. A OWASP lista o SameSite entre as mitigações de linha de frente.

O que é um token CSRF e por que ele funciona?

Um token CSRF é um valor aleatório e imprevisível, gerado pelo servidor para cada sessão. Na aula, o exemplo usa um token de 32 bytes, dificílimo de adivinhar por sorte. O servidor insere esse token dentro de cada formulário legítimo e valida o valor quando o formulário volta.

A proteção nasce de uma regra de segurança do navegador: um site não consegue ler o HTML renderizado de outro site no mesmo browser. O site golpe.com enxerga o próprio formulário, mas nunca o formulário do banco, então não tem como copiar o token verdadeiro. Qualquer submissão sem o token correto é rejeitada.

O guia de prevenção da OWASP detalha como gerar e validar esses tokens por sessão. O ponto de atenção aparece mais adiante neste artigo: o token nunca deve ser colocado na URL, porque URLs vazam em logs, analytics e histórico do navegador.

Header X-CSRF-Token e o preflight do CORS

Uma segunda linha de defesa é exigir um header customizado, como o X-CSRF-Token, em requisições que mudam estado. O HTML puro de um formulário não consegue incluir headers customizados, então o site atacante não consegue forjar o pedido por esse caminho.

Se o atacante tentar usar JavaScript para montar a requisição com o header, entra em cena o CORS. Como o header é customizado, o navegador dispara um preflight, uma requisição OPTIONS que pergunta ao servidor se a origem golpe.com tem permissão. O guia de preflight da MDN explica essa negociação. Na ausência de uma autorização explícita, o pedido é barrado antes de chegar à rota.

Essa combinação funciona porque transforma a proteção de CSRF em uma checagem de origem feita pelo próprio navegador. É por isso que desabilitar o CORS "para testar" é um risco real: você remove o filtro que impede o preflight de bloquear o atacante.

Quais outras defesas existem contra CSRF?

Além de SameSite, token em formulário e header customizado, a indústria usa variações mais fortes e camadas complementares. A tabela abaixo resume as principais opções, suas mecânicas e limitações.

Comparativo das defesas contra CSRF

Cada defesa ataca um elo diferente do golpe, e nenhuma substitui sozinha as demais. Combine mais de uma, começando pelo que o seu framework já entrega.

Defesa	Como funciona	Limitação principal
SameSite=Lax/Strict	Navegador não envia o cookie em requisições cross-site	Strict reduz usabilidade em links externos
Token CSRF em formulário	Servidor valida valor aleatório por sessão	Precisa estar em todo formulário de mudança de estado
Header X-CSRF-Token + CORS	Preflight bloqueia origem sem permissão	Exige JavaScript no cliente
Double submit cookie	Frontend devolve o token como header e o servidor compara	Tem bypasses conhecidos, exige cuidado
Token assinado e amarrado à sessão	Token carrega assinatura vinculada à sessão	Implementação mais trabalhosa
Checagem de Origin no servidor	Servidor confere a origem de cada request sensível	Depende de headers que nem todo cliente envia
MFA em ações sensíveis	Segundo fator confirma a intenção do usuário	Não elimina o ataque, apenas blinda o impacto

O double submit cookie, em que o frontend lê o token e devolve como header para o servidor comparar, é conhecido por ter alguns tipos de bypass. Quando a necessidade é máxima, a recomendação do vídeo e da OWASP converge para o token assinado e amarrado à própria sessão. Para ações críticas, como uma transferência, checar a origem no servidor e exigir um segundo fator reduz o dano mesmo se as outras camadas falharem. É o mesmo princípio do Face ID antes de um Pix ou do código por e-mail numa operação bancária online.

Quem acompanha conteúdos de segurança e desenvolvimento, como o do Gustavo Dev Doido no Crazystack Typescript e o Bootcamp do Dev Doido, encontra esse tema em módulos de back-end e system design. A mensagem é a mesma: leia a documentação do seu framework e descubra quais dessas camadas já vêm ligadas.

CSRF e XSS são o mesmo problema?

Não. CSRF força o navegador a enviar uma requisição com cookies válidos; XSS, ou cross-site scripting, executa JavaScript na sua página. No XSS, um comentário de usuário com HTML mal escapado consegue rodar script dentro do seu domínio, um problema clássico de redes sociais antigas como o MySpace nos anos 2000.

As soluções apresentadas até aqui não foram feitas para XSS. Um script rodando dentro do site legítimo lê o token CSRF, chama APIs e faz tudo que o usuário faria, porque já está dentro da confiança do domínio. Prevenir XSS exige escapar corretamente o HTML renderizado e aplicar políticas de segurança de conteúdo.

A confusão custa caro em revisão de código: alguém troca uma sanitização de input por um token de formulário e acha que resolveu. São dois vetores, duas correções e dois testes diferentes.

Perguntas frequentes sobre CSRF

• O que é cross site request forgery em uma frase? É o ataque em que um site de terceiro faz o navegador da vítima enviar uma requisição autenticada, com cookies válidos, para outro site, executando uma ação sem consentimento do usuário.

• Por que o servidor aceita a requisição forjada? Porque o navegador anexa os cookies de sessão automaticamente em toda requisição ao domínio, inclusive nas originadas de outro site. O servidor valida o cookie e assume que o usuário fez o pedido.

• SameSite=Lax ou Strict para evitar CSRF? Lax já bloqueia a maior parte dos ataques via formulário e preserva logins por link externo. Strict é mais rígido e nem envia o cookie em navegação vinda de outro domínio, exigindo um request interno antes de reconhecer a sessão.

• O token CSRF pode ficar na URL? Não. Nenhuma parte de um sistema trata URL como dado sensível, então o token pode vazar em logs de servidor, ferramentas de analytics, headers de referência e histórico do navegador. Ele pertence ao corpo do formulário ou a um header.

• O CORS sozinho resolve CSRF? Ele ajuda quando a requisição exige um header customizado, porque o preflight barra origens não autorizadas. Mas requisições simples, como formulários HTML, não passam por preflight, então CORS isolado não substitui SameSite nem token.

• Por que desabilitar o CORS é perigoso? Ao desligar a verificação de origem, você remove o mecanismo que impede JavaScript de outros domínios de montar requisições com headers customizados contra sua API. O preflight deixa de existir e o atacante ganha caminho livre.

• CSRF ainda é um problema real em 2026? Os casos diminuíram porque frameworks e navegadores modernos aplicam SameSite e tokens por padrão. A vulnerabilidade volta a existir quando a equipe desliga essas proteções ou monta uma gambiarra em cima do comportamento padrão do framework.

• Qual é a diferença entre CSRF e XSS? CSRF envia requisições em nome da sessão da vítima de fora do site; XSS executa código dentro do site, com acesso a tokens, DOM e APIs internas. Um pede camadas de defesa na requisição, o outro exige escape correto de HTML e políticas de conteúdo.

• Framework já protege contra CSRF? Muitos frameworks populares emitem tokens e configuram cookies com SameSite por padrão. Consulte a documentação oficial do que você usa e confirme quais camadas estão ativas antes de confiar no comportamento padrão.

Do vídeo ao artigo: registre o que você aprende

Se a explicação sobre cross site request forgery fez sentido para você, imagine transformar as aulas de segurança que já existem nos seus vídeos em artigos consultáveis. Vídeo é ótimo para demonstrar o ataque na aba Network; texto indexável é melhor para quem pesquisa a solução depois.

O Skala Blog faz exatamente essa ponte: você cola o link do YouTube, o conteúdo é transcrito e vira um artigo estruturado, pronto para revisar e publicar. Se você já gravou uma aula, uma entrevista ou uma explicação técnica, vale levar esse material para quem busca por ele no Google.

Source video