Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsPara proteger uma aplicação frontend contra CSRF, o servidor precisa verificar, antes de executar cada ação que altera dados, que a requisição foi feita pela própria aplicação e não por um site externo. Um token ou cabeçalho enviado pelo JavaScript do frontend ajuda, mas só protege se o backend validar esse valor. O restante deste guia mostra como escolher o mecanismo certo para a sua arquitetura, como implementá-lo e quais falhas são mais comuns.
Por que o frontend sozinho não resolve o problema
Em aplicações que autenticam o usuário por cookie de sessão, o navegador anexa esse cookie automaticamente a requisições dirigidas ao seu domínio, mesmo quando a requisição foi disparada por outra página. Um atacante aproveita isso: cria uma página ou um formulário que faz o navegador da vítima enviar, por exemplo, uma transferência ou uma troca de senha, e o cookie legítimo acompanha a chamada.
As an Amazon Associate I earn from qualifying purchases.
Por isso, a defesa não pode depender do que o cliente “diz” ser. Um cabeçalho adicionado pelo frontend não impede uma requisição forjada, porque o atacante não está usando o seu código: ele está fazendo o navegador da vítima enviar uma requisição. O servidor é quem decide se aceita a ação, e precisa fazer essa verificação em toda rota que altera estado.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Escolha o mecanismo conforme a arquitetura
A OWASP, na Cross-Site Request Forgery Prevention Cheat Sheet, recomenda padrões diferentes conforme a aplicação mantém ou não estado de sessão no servidor. A tabela resume as opções discutidas na orientação e os cuidados de cada uma.
#1 Best Overall
| Opção | Melhor contexto | Vantagem | Limite ou cuidado |
|---|---|---|---|
| Synchronizer token | Aplicação stateful, com sessão no servidor | O token é comparado com o estado guardado na sessão; é o padrão que a OWASP indica para software stateful | Exige coordenação entre frontend e backend; token por requisição pode causar problemas com os botões voltar e avançar do navegador |
| Double-submit cookie assinado e vinculado à sessão | Aplicação stateless, ou em que manter estado do token no servidor seja difícil | Dispensa armazenar o token no servidor | Exige HMAC correto e comparação em tempo constante; a versão ingênua é vulnerável à injeção de cookies |
Cabeçalho personalizado (por exemplo X-CSRF-Token) |
Frontend e APIs, sobretudo chamadas AJAX ou fetch | Se integra bem a chamadas feitas pelo JavaScript e pode transportar o token | Só tem efeito se o backend validar a requisição; o token não deve ser enviado a outras origens |
Fetch Metadata (Sec-Fetch-Site) |
Navegadores modernos e rotas de alteração de estado | Verificação simples no servidor, sem mudança no cliente | Precisa de fallback para clientes sem esses cabeçalhos; é preciso avaliar fluxos legítimos de navegação entre sites |
| SameSite no cookie | Cookie de sessão em navegadores compatíveis | Reduz o envio do cookie em contextos cross-site | É defesa em profundidade, não substitui token; tem limites com subdomínios, métodos seguros e CSRF client-side |
Ao decidir, considere quatro pontos: se o servidor mantém estado de sessão, quanta coordenação o time consegue manter entre frontend e backend, quais navegadores e clientes precisam ser suportados e se existem subdomínios não confiáveis sob o mesmo domínio registrável.
Antes de qualquer mecanismo próprio, verifique se o framework da sua aplicação já oferece proteção CSRF integrada. A OWASP cita essas proteções como caminho preferencial quando atendem à arquitetura, desde que estejam corretamente configuradas. Um mecanismo artesanal só se justifica quando a integrada não cabe no seu caso.
Padrão para aplicações com sessão no servidor
A OWASP afirma, em texto literal: “Stateful software should use the synchronizer token pattern”. O procedimento abaixo segue esse padrão.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Rank #2
- Comes with secure packaging
- It can be a gift item
- Easy to read text
- Use a proteção do framework, se houver. Localize na documentação do framework em uso o módulo de CSRF e ative-o. Não desative a verificação para rotas que você considera “internas”.
- Gere o token no servidor. Crie um valor secreto e imprevisível, vinculado à sessão do usuário (ou por requisição, se preferir o nível mais estrito).
- Entregue o token ao frontend. Inclua-o no HTML, por exemplo em uma meta tag, ou devolva-o em uma resposta JSON que o JavaScript consulta antes da primeira alteração.
- Envie o token em cada ação protegida. Em formulários HTML, use um campo oculto; em chamadas AJAX ou fetch, use o cabeçalho
X-CSRF-Token. - Valide no servidor antes de processar. Para
POST,PUT,PATCHeDELETE, compare o valor recebido com o da sessão. Se o token estiver ausente ou não bater, rejeite com403e não execute a ação. - Não exponha o token. Não o coloque em URLs, porque a OWASP observa que URLs podem vazar o token pelo histórico do navegador, por arquivos de log e pelo cabeçalho
Referer.
A contrapartida do token por requisição é a experiência de navegação: ao usar voltar ou avançar, o navegador pode reapresentar uma página com um token já invalidado, e o usuário recebe erro. Se isso ocorrer, trate a página recarregada como fonte de um novo token ou use um token por sessão.
Padrão para aplicações stateless
Quando o servidor não guarda estado de sessão, a OWASP recomenda double-submit cookie. Na forma ingênua, o servidor apenas compara o valor do cookie com o valor enviado em campo ou cabeçalho. Esse modelo pode ser enganado por injeção de cookies, porque um atacante capaz de definir um cookie no navegador da vítima também consegue definir o valor esperado.
Em código novo, use a versão assinada e vinculada à sessão:
Rank #3
- Gere o token com HMAC sobre um identificador de sessão ou dados que o atacante não controla, usando uma chave secreta do servidor.
- Inclua no valor assinado um vínculo explícito com a sessão, para que um token válido em uma sessão não sirva em outra.
- Compare o valor recebido com o esperado usando comparação em tempo constante.
- Não registre o token em logs de aplicação, de proxy ou de monitoramento.
Como enviar o token em APIs e SPAs
Em uma aplicação de página única, o cabeçalho próprio é a forma mais natural de apresentar o token, porque as chamadas são feitas pelo JavaScript e não por formulários. Algumas regras evitam que essa solução abra outra brecha:
- Inclua o cabeçalho
X-CSRF-Tokensomente em chamadas para endpoints protegidos do próprio serviço. Uma biblioteca HTTP configurada globalmente pode enviar o token a domínios de terceiros se o filtro não for restrito. - Não confie na configuração do cliente. Um cabeçalho adicionado pelo código do frontend só tem efeito se o backend recusar a requisição quando ele estiver ausente ou incorreto.
- Em rotas que aceitam apenas leitura, como
GET, não exija nem consuma o token para decidir a resposta; o problema está em ações que alteram dados.
Configure os cookies de sessão
O atributo SameSite é uma camada adicional, útil na maioria dos sistemas, mas não substitui token. Um exemplo de cabeçalho de resposta para um cookie de sessão em HTTPS:
Set-Cookie: __Host-sid=valor; Path=/; Secure; HttpOnly; SameSite=LaxAlgumas regras de configuração:
SameSite=NoneexigeSecure. UseNonesomente se o cookie precisar ser enviado em contextos cross-site, pois isso reduz a proteção que o atributo oferece.- O prefixo
__Host-impede o atributoDomain, exigePath=/e exigeSecure. Ele é adequado quando a aplicação roda em um único host HTTPS. HttpOnlyimpede que o JavaScript leia o cookie. Isso não protege contra CSRF por si só, mas reduz o risco de vazamento de sessão por XSS.
Mesmo com SameSite configurado, mantenha os tokens. O atributo não cobre ações alteráveis feitas por métodos considerados seguros, requisições same-site vindas de subdomínios e ataques em que o próprio JavaScript da aplicação é induzido a enviar uma ação.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Fetch Metadata e verificação de Origin ou Referer
O cabeçalho Sec-Fetch-Site informa se a requisição veio da mesma origem, do mesmo site, de um site cruzado ou de um acesso direto. Em rotas que alteram estado, o servidor pode rejeitar requisições marcadas como cross-site.
Esse controle tem dois cuidados. Primeiro, clientes antigos ou incorporados podem não enviar o cabeçalho, então é preciso um fallback: verifique o cabeçalho Origin e, se ele estiver ausente, o Referer. Segundo, alguns fluxos legítimos, como retorno de um provedor de login ou de um pagamento externo, chegam como cross-site; teste esses caminhos antes de bloquear.
A OWASP afirma que Fetch Metadata é suportado em todos os principais navegadores desde março de 2023 e declara cobertura global superior a 98%. A página consultada não indica o ano de publicação, então trate esse número como afirmação da própria OWASP, e não como medição independente.
CSRF do lado do cliente
Existe um padrão que tokens e SameSite podem não neutralizar: o JavaScript da aplicação lê um parâmetro controlado pelo atacante, como um trecho da URL, e usa esse valor para decidir o método, o destino ou o corpo de uma chamada autenticada. Como a chamada sai do próprio código, ela leva o token e o cookie válidos.
Um exemplo típico é uma rota que lê ?acao=excluir&id=42 e dispara um fetch com o método e o endereço vindos da URL. A correção está no frontend: restrinja essas ações a uma lista fixa de valores permitidos, defina o método e o endereço no código, e nunca os derive diretamente de parâmetros de navegação. O backend também deve exigir confirmação explícita para ações sensíveis.
Erros comuns e como identificá-los
- Token validado só no frontend. Sintoma: a ação é recusada na tela, mas uma requisição feita com ferramenta de linha de comando ainda é processada. Correção: mover a checagem para o servidor.
- Ações alteráveis em
GET. Sintoma: um link ou imagem em outro site executa a ação. Correção: mover a alteração paraPOST,PUT,PATCHouDELETE, sempre protegidos. - Token na URL ou em logs. Sintoma: o valor aparece em histórico, registros de acesso ou no
Refererenviado a terceiros. Correção: enviar sempre no corpo ou em cabeçalho. - Erro 403 depois do login. Sintoma: o primeiro formulário funciona, mas o seguinte falha. Causa comum: o token foi renovado ou invalidado sem que o frontend recebesse o valor novo.
- Implementação stateless ingênua. Sintoma: o servidor aceita um cookie definido por outra origem como prova de token válido. Correção: assinar o token e vinculá-lo à sessão.
Para verificar a proteção, faça login na aplicação e, a partir de outra página, tente disparar uma ação alterável. A requisição deve ser recusada pelo servidor, e não apenas pela interface.
Próximos passos
Comece pelo inventário: liste todas as rotas que alteram dados e confirme que cada uma exige validação no servidor. Depois, adote a proteção integrada do framework, complemente com SameSite e Fetch Metadata e revise o código do frontend em busca de ações definidas por parâmetros de URL.
Fonte principal deste guia: OWASP, Cross-Site Request Forgery Prevention Cheat Sheet, da OWASP Cheat Sheet Series. Consulte a versão atual dessa página antes de implementar, porque os detalhes de cada padrão podem ser atualizados.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
