Verificar cabeçalhos CORS

Cole um bloco de cabeçalhos para confirmar a presença de Access-Control-Allow-Origin, detectar a combinação insegura de origem curinga com credenciais e identificar a ausência de Vary: Origin quando uma origem específica é permitida. O resultado é determinístico e explica cada achado, sendo útil em revisões de implantação, investigação de incidentes, verificações automatizadas e reforço rotineiro de API, sem enviar uma solicitação ao servidor de destino.

Interprete o resultado como uma revisão direcionada

Comece copiando os cabeçalhos de resposta exatamente como foram recebidos pelo navegador ou cliente de linha de comando, com um par Nome: valor por linha. Os nomes são comparados sem diferenciação entre maiúsculas e minúsculas, e valores de Vary separados por vírgulas são tratados como itens individuais. O verificador exige Access-Control-Allow-Origin porque não existe uma política CORS de resposta para avaliar sem esse cabeçalho; portanto, sua ausência gera um erro de entrada, e não um relatório inconclusivo. Um relatório bem-sucedido retorna a origem permitida normalizada, informa se as credenciais estão habilitadas, indica se a resposta varia por Origin e apresenta uma lista ordenada de achados. O campo valid significa que nenhum problema com gravidade de erro foi detectado. Ainda pode existir um aviso, então sistemas consumidores também devem examinar issue_count e issues. Esse escopo restrito é proposital: oferece fatos estáveis sobre dois erros comuns sem alegar que todo o modelo de autorização do aplicativo é seguro. Guarde a resposta original e a origem da solicitação com o resultado quando a verificação fizer parte de uma auditoria.

Entenda origens curinga e solicitações com credenciais

Access-Control-Allow-Origin: * é conveniente para recursos realmente públicos e sem credenciais, pois permite que qualquer origem solicitante leia a resposta. Ele não deve ser combinado com Access-Control-Allow-Credentials: true. Os navegadores rejeitam essa combinação no acesso CORS com credenciais, e a configuração frequentemente revela que o limite de confiança pretendido pelo servidor não foi expresso corretamente. O verificador registra essa combinação como wildcard_origin_with_credentials com gravidade de erro. A correção não é refletir automaticamente todo Origin recebido. Defina quais origens são confiáveis, compare o Origin da solicitação com uma lista explícita de permissões e emita apenas uma origem aprovada após uma correspondência. Se cookies ou outras credenciais ambientais não forem necessários, desative o suporte a credenciais e mantenha a política pública com curinga. Lembre-se também de que CORS controla se scripts do navegador podem ler uma resposta; não é autenticação, autorização, proteção contra falsificação de solicitações nem firewall. Revise separadamente atributos de cookies, controles de autorização, métodos, cabeçalhos expostos e comportamento de preflight antes de considerar o endpoint seguro.

Use Vary: Origin para manter caches compartilhados corretos

Quando um servidor escolhe um valor específico de Access-Control-Allow-Origin conforme o Origin da solicitação, a representação da resposta depende efetivamente desse cabeçalho. Vary: Origin informa a navegadores, proxies reversos e redes de distribuição de conteúdo que respostas produzidas para origens diferentes não podem ser tratadas como equivalentes. Sem ele, um cache pode reutilizar em outra solicitação uma resposta que contém a origem permitida de um locatário, provocando falhas intermitentes e possivelmente enfraquecendo as premissas da política para conteúdo armazenado. Por isso, o verificador emite missing_vary_origin quando a origem permitida é específica e Vary não contém Origin nem o token curinga. Ele aceita Origin em uma linha Vary separada por vírgulas e também em cabeçalhos Vary repetidos. O achado é um aviso porque uma resposta colada não revela se o valor da origem é constante em todas as solicitações ou se o cache está desabilitado em outro ponto. Confirme a lógica real de seleção do servidor e as diretivas de cache antes de alterar a produção. Se a origem for refletida dinamicamente após validação por lista de permissões, adicionar Origin a Vary costuma ser o sinal de cache mais claro e seguro.