Configuração incorreta de CORS: como funciona, como detectar e como corrigir
CORS permissivo demais - uma Origin refletida com credentials, um wildcard ou um origin null permitido - deixa sites maliciosos lerem respostas autenticadas.
Severidade típica: Alta · Verificado pelo módulo da NovaPentest: CORS
O que é
O Cross-Origin Resource Sharing (CORS) é o mecanismo do browser que relaxa a Same-Origin Policy para que uma página de uma origem possa ler respostas de outra. O servidor controla isso com headers de resposta - principalmente o Access-Control-Allow-Origin (ACAO), que indica a origem autorizada a ler a resposta, e o Access-Control-Allow-Credentials (ACAC), que, quando é "true", deixa a requisição cross-origin levar cookies e authorization.
Uma configuração incorreta é qualquer política que confia em origens que não deveria. O padrão mais perigoso é refletir o header Origin de quem chama de volta no ACAO enquanto também envia ACAC: true - na prática, "qualquer site pode ler esta resposta autenticada". Como a requisição carrega os cookies da vítima, uma página maliciosa consegue ler dados como se fosse ela. Um wildcard (ACAO: *) é menos grave porque o browser se recusa a enviar credentials com ele, mas ainda expõe qualquer API sensível sem autenticação. Aceitar o valor especial "null" também é inseguro: a origem null é produzida por iframes em sandbox, documentos data: e arquivos locais, então um atacante a apresenta com facilidade. Lógica fraca de allowlist - casar substring, um domínio confiável como prefixo ou sufixo, ou confiar em subdomínios passíveis de takeover - cai na mesma família.
O CORS controla o que scripts podem ler, não se a requisição chega ao servidor, então é fundamentalmente um controle de confidencialidade. Esses problemas se mapeiam a OWASP Broken Access Control / Security Misconfiguration e a CWE-942 (política cross-domain permissiva demais).
Como é explorada
Configurações incorretas de CORS são exploradas a partir do browser da vítima. O atacante atrai um usuário autenticado a uma página sob seu controle; essa página roda JavaScript que faz um fetch cross-origin à API vulnerável com as credentials incluídas. Se o servidor reflete a origem da página do atacante no Access-Control-Allow-Origin e retorna Access-Control-Allow-Credentials: true, o browser deixa o script do atacante ler a resposta - que foi gerada usando os cookies de sessão da vítima.
O script então exfiltra o que o endpoint retornar: dados de perfil, API keys, tokens CSRF, detalhes de conta ou qualquer coisa que a vítima esteja autorizada a ver. Ler um token CSRF assim pode encadear em requisições que alteram estado, escalando de uma leitura para account takeover. A variante de origin null funciona do mesmo jeito, mas é disparada de um iframe em sandbox ou de um documento local que apresenta Origin: null, útil quando o servidor trata null como caso especial.
Um wildcard puro (ACAO: *) não pode ser combinado com credentials pelo browser, então não expõe dados autenticados por cookie; seu risco se limita a endpoints que retornam informação sensível sem depender de cookies, ou que autenticam por um bearer token que a página do atacante consegue fornecer. Nenhum exploit de servidor é necessário - o browser entrega a resposta de bom grado porque o servidor disse que a origem era confiável. O impacto vai de vazamento de dados sensíveis a account takeover completo quando tokens ou segredos CSRF são expostos.
Como detectar
O módulo de CORS da NovaPentest testa o alvo com headers Origin forjados e lê os headers CORS da resposta. Primeiro envia um GET com uma origem arbitrária de atacante (https://evil-pentgen-test.com) e inspeciona o Access-Control-Allow-Origin e o Access-Control-Allow-Credentials. Se o ACAO é exatamente "*", reporta um wildcard de origem como Medium. Se, em vez disso, o servidor reflete de volta exatamente a origem maliciosa, reporta reflexão de origem arbitrária - High por si só, e Critical quando o Access-Control-Allow-Credentials também é "true", porque origem refletida somada a credentials é o padrão de account takeover.
Em seguida envia um segundo GET com Origin: null; se o servidor responde com Access-Control-Allow-Origin: null, reporta que a origem null é permitida, como High. O módulo raciocina apenas sobre esses headers de resposta, então detecta reflexão, wildcard e confiança em origin null, e não toda variação possível de bypass de allowlist.
Para conferir manualmente, rode `curl -sI -H "Origin: https://evil.example" https://api.alvo.com/endpoint` e observe o Access-Control-Allow-Origin e o Access-Control-Allow-Credentials retornados; repita com `-H "Origin: null"`. Uma resposta que ecoa sua origem arbitrária - sobretudo junto de Allow-Credentials: true - confirma a falha. Teste também origens quase iguais (um domínio confiável com um prefixo ou sufixo a mais, ou um look-alike) para expor casamento de allowlist mal feito que a checagem automática não tenta.
Como corrigir
1. Use uma allowlist explícita. Compare a Origin recebida com um conjunto fixo de origens exatas e confiáveis (scheme + host + porta completos) e só então ecoe esse mesmo valor no Access-Control-Allow-Origin. Nunca reflita o header Origin às cegas.
2. Nunca combine reflexão ou wildcard com credentials. Se Access-Control-Allow-Credentials: true for necessário, o ACAO deve ser uma origem específica - nunca "*", nunca um valor arbitrário refletido dinamicamente.
3. Rejeite a origin null. Não inclua "null" na allowlist; trate requisições que apresentam Origin: null como não confiáveis.
4. Case as origens de forma exata. Evite checagens por substring, prefixo ou sufixo e regexes que podem ser enganados (por exemplo "example.com.atacante.com" ou "atacante-example.com"); ancore a comparação na string de origem inteira.
5. Restrinja o escopo. Aplique CORS apenas a endpoints que realmente precisam de acesso cross-origin, mantenha wildcards fora de qualquer endpoint que retorne dados sensíveis ou autenticados e limite Access-Control-Allow-Methods e -Headers ao necessário.
6. Não dependa de CORS para autorização. Ele governa o que os browsers podem ler, não quem pode chamar a API; mantenha o controle de acesso no servidor e as defesas de CSRF de qualquer forma.
7. Cuide dos subdomínios. Se sua allowlist confia em subdomínios, garanta que nenhum seja passível de takeover, ou um subdomínio reivindicado vira uma origem confiável.
Priorize origem refletida com credentials (Critical) primeiro, depois origin null e reflexão simples, e por fim wildcards em endpoints sensíveis.
Verifique o seu próprio site
Comece pelo scan passivo gratuito: não precisa de conta e você recebe uma nota de A a F cobrindo cabeçalhos, TLS, cookies, DNS e outras configurações que qualquer visitante consegue observar. Ele não envia payloads de ataque, então não confirma todas as classes de falha. O scan completo, disponível com uma conta gratuita, executa as verificações ativas, incluindo a descrita nesta página.