Resposta rápida: CORS, CSRF e CSP não são três nomes para o mesmo problema. CORS é um mecanismo do navegador, baseado em cabeçalhos HTTP, que define quando código de uma origem pode ler uma resposta de outra origem. CSRF é um ataque em que o navegador da vítima é induzido a enviar uma requisição autenticada que ela não pretendia fazer. CSP é uma política enviada pelo site ao navegador para limitar quais recursos e códigos uma página pode carregar ou executar. Em termos práticos: problema para ler uma API de outra origem aponta para CORS; ação indevida feita com a sessão do usuário aponta para CSRF; script, frame ou recurso não autorizado executado ou carregado na página aponta para CSP.
Por que CORS, CSRF e CSP acabam misturados
Os três aparecem em segurança web, envolvem decisões tomadas pelo navegador e costumam surgir em depuração de front-end. Além disso, todos podem citar conceitos como origem, cabeçalhos HTTP e recursos externos. A semelhança termina aí. Cada um responde a uma pergunta diferente e atua em uma direção diferente do fluxo.
Para CORS, a pergunta é se o navegador pode expor ao JavaScript de uma origem uma resposta recebida de outra. Para CSRF, a pergunta é se um site atacante consegue provocar uma ação no servidor alvo usando credenciais que o navegador envia automaticamente, como cookies de sessão. Para CSP, a pergunta é o que o documento já carregado tem permissão para executar, buscar ou incorporar.
Matriz: CORS x CSRF x CSP
| Aspecto | CORS | CSRF | CSP |
|---|---|---|---|
| O que é | Mecanismo de compartilhamento entre origens baseado em cabeçalhos HTTP | Ataque de falsificação de requisição em contexto autenticado | Política de segurança de conteúdo aplicada pelo navegador |
| Pergunta central | Este JavaScript pode ler a resposta desta outra origem? | Outro site consegue fazer o navegador do usuário executar uma ação autenticada? | Quais recursos e formas de execução esta página pode usar? |
| Camada principal | Navegador e resposta do servidor que fornece o recurso | Aplicação e servidor que recebem ações autenticadas | Navegador seguindo a política declarada pelo site |
| Problema típico | Fetch ou XMLHttpRequest bloqueado por política de origem | POST, PUT, PATCH ou DELETE indesejado usando a sessão da vítima | Execução de script injetado, carga de recurso não autorizado ou embedding indevido |
| Controles comuns | Access-Control-Allow-Origin, preflight, métodos e cabeçalhos permitidos, credenciais | Token anti-CSRF, SameSite, validação de Origin ou Referer, Fetch Metadata, cabeçalhos customizados | Content-Security-Policy com diretivas como script-src, default-src, connect-src e frame-ancestors |
| O que não substitui | Autenticação, autorização e proteção anti-CSRF | Validação de autorização, correção de XSS e política de carregamento de recursos | Sanitização de entrada, autorização, CORS ou proteção anti-CSRF |
| Sinal de debugging | Erro CORS no console, preflight OPTIONS ou resposta não exposta ao script | A ação acontece sem intenção do usuário quando ele já está autenticado | O console relata violação de Content Security Policy ou um recurso é bloqueado pela diretiva |
CORS: permissão para leitura entre origens
A política de mesma origem restringe como um documento ou script de uma origem interage com recursos de outra. Uma origem é determinada pelo conjunto de esquema, host e porta. CORS, sigla de Cross-Origin Resource Sharing, permite que o servidor informe ao navegador quais outras origens podem acessar uma resposta em contexto cross-origin.
O cabeçalho mais conhecido é Access-Control-Allow-Origin. Dependendo da requisição, o navegador pode enviar antes um preflight com método OPTIONS para perguntar quais métodos e cabeçalhos são permitidos. Se a resposta não satisfizer a política, o JavaScript não recebe acesso normal ao conteúdo da resposta.
O ponto que mais evita confusão é este: CORS é principalmente uma regra sobre o navegador compartilhar a resposta com o código chamador. Ele não é um firewall de servidor e não substitui autenticação ou autorização. Clientes fora do navegador, como serviços backend e ferramentas HTTP, não dependem do bloqueio de CORS para decidir se podem fazer uma chamada.
Por que um erro de CORS não significa que a requisição nunca chegou
Algumas requisições chamadas de simples podem ser enviadas sem preflight, incluindo certos GET, HEAD e POST com cabeçalhos e tipos de conteúdo limitados. O servidor precisa continuar tratando a requisição com segurança. Se a origem não estiver autorizada por CORS, o navegador pode ocultar a resposta do JavaScript atacante, mas isso não desfaz um efeito que o servidor já executou. Essa é uma das razões pelas quais CORS não deve ser tratado como defesa contra CSRF.
Outro detalhe frequente é o uso de credenciais. Quando uma resposta CORS é compartilhada com uma requisição que inclui credenciais, a configuração precisa ser mais restrita. O curinga em Access-Control-Allow-Origin não serve como permissão genérica para respostas credenciadas, e políticas de cookies de terceiros continuam sendo aplicadas pelo navegador.
CSRF: o problema é a ação forjada, não a leitura da resposta
Cross-Site Request Forgery explora o fato de que navegadores podem anexar credenciais automaticamente a uma requisição, especialmente cookies de sessão. Um atacante prepara uma página ou fluxo que faz o navegador da vítima enviar uma requisição para a aplicação em que ela já está autenticada. Se o servidor aceitar a requisição apenas porque o cookie de sessão está presente, uma ação pode ocorrer sem intenção do usuário.
O atacante não precisa necessariamente ler a resposta para que o ataque tenha sucesso. Se uma operação como alterar e-mail, adicionar uma chave, mudar uma configuração ou iniciar uma transação for concluída no servidor, bloquear a leitura da resposta por CORS não corrige a falha.
Defesas que realmente pertencem ao problema de CSRF
- Token anti-CSRF: aplicações com estado podem usar o padrão de token sincronizado, em que o servidor emite um valor secreto e imprevisível e valida esse valor em requisições que alteram estado.
- SameSite em cookies: reduz o envio de cookies em vários contextos cross-site. A OWASP trata SameSite como uma camada importante, mas não como substituto universal para controles anti-CSRF.
- Verificação de origem: o servidor pode validar Origin e, em cenários de fallback, Referer, comparando a origem da requisição com o destino esperado.
- Fetch Metadata: cabeçalhos como Sec-Fetch-Site fornecem contexto adicional para bloquear requisições cross-site suspeitas.
- Cabeçalho customizado em APIs: em arquiteturas AJAX ou API, exigir um cabeçalho que um site externo não consegue acrescentar como requisição simples pode compor a defesa, desde que a política CORS seja restrita e a API não aceite formatos simples inseguros como alternativa.
As defesas precisam combinar com a arquitetura. Um formulário tradicional, uma SPA que usa cookies e uma API autenticada com token explícito têm superfícies diferentes. Também é importante evitar que requisições GET façam mudanças de estado, pois métodos considerados seguros têm comportamento especial em navegadores e em políticas de cookies.
CSP: restringir o que a página pode carregar e executar
Content Security Policy é entregue principalmente pelo cabeçalho de resposta Content-Security-Policy. A política contém diretivas que instruem o navegador sobre fontes e comportamentos permitidos. script-src controla origens e formas permitidas para JavaScript; style-src faz o mesmo para estilos; img-src controla imagens; connect-src restringe destinos de conexões iniciadas por scripts; frame-ancestors controla quem pode incorporar a página.
Um dos principais usos de CSP é reduzir o risco e o impacto de XSS. Uma política estrita pode bloquear scripts inline não autorizados, event handlers inline, URLs com esquema JavaScript e fontes externas que não estejam permitidas. Nonces ou hashes podem autorizar scripts específicos sem liberar execução inline de forma ampla.
CSP é defesa em profundidade. Ela não torna seguro inserir entrada não sanitizada no HTML e não substitui encoding e sanitização. Também não decide se um servidor remoto deve compartilhar sua resposta com outra origem, que é o papel de CORS, nem valida se uma ação autenticada foi realmente solicitada pelo usuário, que é o problema de CSRF.
Por que connect-src ainda não transforma CSP em CORS
connect-src pode impedir que a página atual faça fetch, XMLHttpRequest, WebSocket e conexões relacionadas para destinos não autorizados. Isso parece CORS à primeira vista, mas a direção é diferente. CSP é uma regra declarada pelo site da página para restringir o comportamento daquela página. CORS é a resposta do servidor de destino dizendo ao navegador se a resposta cross-origin pode ser exposta ao código chamador. Em uma mesma chamada, os dois controles podem existir ao mesmo tempo.
Três mini cenários para identificar o conceito certo
Cenário 1: a SPA chama a API e o console mostra bloqueio por origem
O front-end em https://app.example chama https://api.example e a API funciona quando testada por uma ferramenta HTTP, mas o navegador não entrega a resposta ao JavaScript. O primeiro conceito a verificar é CORS: Access-Control-Allow-Origin, preflight, métodos, cabeçalhos e credenciais. A autenticação da API continua sendo uma questão separada.
Cenário 2: um site externo dispara a troca de e-mail de um usuário logado
A aplicação usa cookie de sessão. O usuário visita um site malicioso que consegue enviar uma requisição compatível com um formulário para o endpoint de troca de e-mail. A resposta nem precisa ser lida. Se o servidor executa a alteração só porque recebeu o cookie, o problema é CSRF. A defesa precisa validar intenção, por exemplo com token, SameSite apropriado, verificação de origem ou controles equivalentes para a arquitetura.
Cenário 3: um campo de comentário permite executar JavaScript injetado
A vulnerabilidade principal é XSS, e CSP pode reduzir a capacidade do payload de executar ou carregar código não autorizado. A correção da origem do problema continua sendo tratar a entrada e a saída corretamente. Uma política estrita funciona como defesa em profundidade. Configurar CORS não corrige a injeção, e token anti-CSRF não impede JavaScript que já está executando dentro da origem confiável.
Como escolher rapidamente qual defesa investigar
- Se a falha é ler uma resposta cross-origin no navegador, investigue CORS e a política de mesma origem.
- Se a falha é uma ação autenticada acontecer sem intenção do usuário, investigue CSRF e como o servidor valida requisições que alteram estado.
- Se a falha é código ou recurso não autorizado executar, carregar ou ser incorporado, investigue CSP e, se houver injeção, a causa de XSS.
- Se mais de um item aparece no mesmo fluxo, trate cada camada separadamente. É comum uma SPA precisar de CORS correto, proteção anti-CSRF por usar cookies e uma CSP estrita ao mesmo tempo.
Erros de configuração que mantêm a confusão
- Liberar Access-Control-Allow-Origin de forma ampla para resolver qualquer erro: corrige sintomas de integração, mas pode expor respostas a origens desnecessárias e não cria autorização de aplicação.
- Confiar no preflight como barreira anti-CSRF: requisições simples existem justamente por compatibilidade com formas históricas de envio cross-site. O endpoint precisa de controles próprios.
- Usar CSP como substituto para sanitização: CSP reduz vetores de execução, mas a própria MDN recomenda tratá-la como parte de uma estratégia maior contra XSS.
- Tratar Origin como identidade do usuário: origem ajuda em políticas de navegador e em verificações anti-CSRF, mas autenticação e autorização continuam exigindo controles próprios no servidor.
- Esquecer que XSS pode enfraquecer a defesa contra CSRF: código malicioso executando na origem da aplicação pode, em muitos cenários, ler tokens disponíveis ao JavaScript e enviar requisições como se fosse a própria aplicação.
Uma forma de memorizar
CORS fala de compartilhar respostas entre origens. CSRF fala de forjar ações autenticadas. CSP fala de limitar o comportamento e os recursos da página. A defesa correta nasce da pergunta correta: quem está tentando ler, quem está tentando agir e o que a página está autorizada a executar ou carregar.
