🛂 Segurança

Explicador de CORS preflight

Recebe método+headers da requisição CORS e mostra se vai disparar preflight OPTIONS e por quê.

Método HTTP Content-Type (se POST/PUT) Headers customizados (um por linha, ex: Authorization, X-Csrf-Token) Diagnóstico CORS

—

Por que aquele OPTIONS aparece antes da sua requisição

Toda vez que o JavaScript de um site chama uma URL em outra origem, o navegador precisa decidir se manda a requisição direto ou se pergunta antes. Essa pergunta é o preflight: uma requisição OPTIONS que não faz nada além de checar se o servidor autoriza o método e os cabeçalhos que virão em seguida. Quem não conhece a regra vê o OPTIONS no log e acha que o cliente está com defeito.

A regra é a definição de requisição simples. Vale método GET, HEAD ou POST; Content-Type limitado a form-urlencoded, multipart/form-data ou text/plain; e nenhum cabeçalho fora da lista segura. Qualquer desvio dispara o preflight. Escolha o método, o Content-Type e liste os cabeçalhos customizados: a página diz se vai haver OPTIONS e, principalmente, qual condição foi violada.

Na prática, quase toda API moderna cai no preflight, e por dois motivos que aparecem juntos: application/json não está na lista de tipos simples, e Authorization não está na lista de cabeçalhos seguros. Isso não é problema — é o funcionamento normal. O que resolve é o servidor responder ao OPTIONS com os cabeçalhos de permissão e um Access-Control-Max-Age, que faz o navegador guardar a autorização em cache e parar de perguntar a cada chamada.

Perguntas frequentes

Por que meu POST com JSON dispara preflight se POST é método simples?

Porque o método é só uma das três condições. O Content-Type application/json não está entre os tipos simples, e isso basta. Enviando os mesmos dados como text/plain o preflight some — mas aí o servidor precisa fazer o parse manualmente, o que raramente compensa.

O preflight leva cookie e cabeçalho de autenticação?

Não. A requisição OPTIONS vai sem credenciais e sem o corpo, de propósito: ela é só uma pergunta. Por isso o servidor precisa responder ao OPTIONS antes de qualquer verificação de autenticação — middleware que exige token e é executado cedo demais bloqueia o preflight e derruba a chamada real.

Access-Control-Allow-Origin com * resolve tudo?

Resolve o caso sem credenciais. Quando a requisição envia cookie ou usa credentials include, o navegador rejeita o asterisco: é preciso devolver a origem exata e acrescentar Access-Control-Allow-Credentials true. Nesse cenário, ecoar qualquer origem recebida é um risco — mantenha uma lista de origens permitidas.

Ferramentas Relacionadas

🌐

Validador de Configuração CORS

Valide uma configuração de CORS (origens permitidas ou *), conferindo o formato e duplicatas. Útil para configurar APIs e servidores web com segurança.

📄

Verificador X-Content-Type-Options

Confirma se X-Content-Type-Options está como nosniff e explica riscos de MIME-sniffing quando ausente.

🧱

Gerador de Headers COOP / COEP

Gere os cabeçalhos HTTP COOP e COEP (Cross-Origin Opener/Embedder Policy) para isolar a sua origem. Necessário para usar SharedArrayBuffer com segurança.

🔒

HSTS Header Builder

Monta o header Strict-Transport-Security a partir das opções.

🔒

Gerador de Header HSTS

Monta o header Strict-Transport-Security com max-age, includeSubDomains e preload conforme escolha.

🪪

Explicador de claims JWT

Lista todas as claims registradas (iss, sub, aud, exp, nbf, iat, jti) com descrição e validação básica do payload.