O que é CSRF e como proteger uma aplicação de solicitações falsificadas?
Publicado em 2026-10-20 por frfrand
Ataques CSRF explicados con cookies, acciones involuntarias, tokens anti-CSRF, SameSite y defensas del servidor.
CSRF é um ataque que tenta aproveitar que o navegador de uma pessoa autenticada pode enviar solicitações a um site sem que essa pessoa tenha querido realizar a ação. Significa Cross-Site Request Forgery, ou falsificação de solicitações entre sites.
A chave está em que um site pode reconhecer uma sessão por meio de cookies. Um atacante tenta provocar que o navegador envie uma operação aproveitando essa identidade.
O exemplo de uma ordem que você nunca deu
Imaginá que entrás no seu banco e deixás a sessão aberta. Depois visitás uma página desconhecida que tenta provocar uma solicitação para modificar algum dado da sua conta.
Se o banco aceitasse a operação apenas porque chegou com um cookie válido, poderia tratar uma ação indesejada como se você a tivesse solicitado. Um design correto verifica algo mais do que «há uma sessão iniciada».
Não significa que qualquer site possa ler seus dados bancários: a política de mesma origem limita muitas leituras entre páginas. Impedir ler uma resposta e evitar que uma solicitação seja enviada são problemas diferentes.
Qual papel têm os cookies?
O navegador pode anexar cookies a solicitações de acordo com o domínio, as políticas do cookie e o contexto de navegação. Essa comodidade permite manter sessões, mas também exige proteger ações sensíveis.
Atributos como SameSite ajudam a restringir quando os cookies são enviados entre sites. São uma defesa útil, embora não substituam todas as verificações do servidor e exijam a escolha de uma política adequada ao produto.
O que é um token anti-CSRF?
Muitas aplicações geram um valor que o atacante não deveria conhecer e exigem que ele apareça nas operações que modificam informações. O servidor verifica se corresponde à sessão ou contexto esperado.
Frameworks como o Django incluem proteções e mecanismos de verificação para formulários e solicitações que alteram o estado. Mas continuam dependendo de uma configuração correta: desativar proteções para «fazer o frontend funcionar» pode criar um problema sério.
O CORS resolve CSRF?
Não. O CORS regula determinados acessos entre origens a partir de navegadores, mas não foi projetado para substituir uma defesa anti-CSRF. Uma solicitação pode produzir efeitos no servidor mesmo quando o navegador não permite ler sua resposta.
Também não convém confundir CSRF com XSS. No XSS, o atacante consegue executar código não confiável dentro do contexto de uma página. Ambos os problemas podem estar relacionados, mas suas causas e mitigações são diferentes.
Quais operações precisam de atenção?
Alterar uma senha, modificar um e-mail, transferir fundos, adicionar usuários ou excluir registros são exemplos de ações cuja origem legítima deve ser verificada.
As solicitações GET, por convenção, não deveriam modificar estado. Se visitar uma URL desencadear uma exclusão, além do possível CSRF, há uma decisão de design HTTP incorreta.
Como verificar a proteção?
Teste que um formulário legítimo funciona e que uma operação sem o token ou contexto necessário é rejeitada. Revise também o que acontece quando a sessão expira e quando a requisição vem de uma origem inesperada.
Não faça testes de segurança contra serviços alheios sem permissão. Um ambiente de testes próprio permite verificar configurações sem colocar em risco dados reais.
O que isso significa na ArduMaker?
Se hospedar em um VPS da ArduMaker um aplicativo que usa cookies de sessão, seu backend deve aplicar defesas CSRF adequadas. O fato de implantá-la sob HTTPS não elimina automaticamente esse risco.
Em resumo: CSRF tenta converter a sessão de um usuário legítimo em uma operação que ele não autorizou. A defesa requer validar a intenção da solicitação, além da identidade.
Fontes: OWASP CSRF Prevention Cheat Sheet · Proteção CSRF do Django.