01
Escolha a Origin do frontend
Informe esquema, host e porta do site que chama a API, não o endereço da API. A análise local simula essa Origin; o GET real usa a Origin fixa do HeyUtils.
HTTP / Depuração de requisições
verificador CORSpara saber o que o navegador lê
Cole a resposta real e, se preciso, a resposta OPTIONS. O GET de rede é sempre manual.
verificador CORS
Cabeçalhos da resposta real
Cabeçalhos OPTIONS (opcionais)
Os cabeçalhos colados são analisados no navegador, sem enviar requisições.
Resultado
Cole cabeçalhos de resposta para começar.
Condições da requisição
Esta Origin serve apenas à análise local. O GET usa a Origin real desta página.
Cole cabeçalhos de resposta para começar.
A API registra HTTP 200, mas fetch falha. O verificador CORS separa a chegada da resposta ao navegador da permissão para que o JavaScript leia seus dados.
Para testar CORS localmente, informe a Origin do frontend, método e nomes de cabeçalhos. Se houver preflight, compare também a resposta OPTIONS; colar cabeçalhos não acessa o servidor.
Por que usar o verificador CORS
Receber uma resposta e poder lê-la são etapas distintas.
Um 200 pode continuar oculto
Um GET simples pode chegar ao servidor, mas o navegador bloqueia sua leitura sem Allow-Origin adequado na resposta real. O verificador CORS não transforma sucesso HTTP em permissão.
OPTIONS merece análise separada
POST com JSON e Authorization podem exigir preflight. Sem a resposta OPTIONS, sua aprovação é desconhecida. Cole status, métodos e cabeçalhos permitidos para descobrir a condição recusada.
Acompanhe as duas permissões
02
Identifique quando há preflight
Uma solicitação de preflight pode ocorrer com application/json, Authorization e métodos não simples. Os nomes dos cabeçalhos bastam para classificar. Sem resposta OPTIONS, a autorização fica não verificada.
03
Exporte só o resultado atual
Qualquer alteração desativa cópia e download antigos. A análise automática espera 350 ms; desligue para usar o botão ou Ctrl/Cmd + Enter.
Cada regra de acesso em separado
Origin e credenciais
Allow-Origin: * falha com credentials: include. Mesmo uma Origin específica exige Allow-Credentials: true. O cabeçalho Authorization não equivale ao modo de credenciais.
Método e cabeçalhos aceitos
O verificador de preflight lê status OPTIONS, Allow-Methods e Allow-Headers e aponta precisamente o método ou nome que falta.
Cabeçalhos visíveis e cache
Mostra Expose-Headers e Vary: Origin. Uma resposta isolada não comprova que o servidor reflita qualquer origem.
GET real sob seu controle
Somente o clique envia GET sem credenciais da página atual. Um HTTP 404 ainda pode ser legível; quando fetch falha, status e cabeçalhos ficam ocultos.
O que o resultado não comprova
- Cabeçalhos colados são simulação
- Verificar cabeçalhos CORS localmente usa o texto fornecido, não uma resposta ao vivo. Se a requisição exige OPTIONS e essa resposta falta, a conclusão é não verificada.
- Origin de navegador não pode ser forjada
- O verificador CORS direto não envia a partir do seu frontend nem inclui POST, Cookie ou valores personalizados. Sucesso na mesma origem não demonstra acesso entre origens.
- Sem proxy nem varredura
- A ferramenta não repassa URLs arbitrárias por um servidor, não varre várias Origins e não envia métodos que alteram dados. Ausência de Allow-Origin pode ser normal em recursos só da mesma origem.
- Cabeçalho oculto não é ausente
- O script lê apenas cabeçalhos liberados por padrão ou em Expose-Headers. Veja DevTools ou logs do alvo para o intercâmbio completo.
Dúvidas sobre o verificador CORS
Por que uma requisição falha com erro de CORS mesmo que o servidor tenha respondido com sucesso?
O servidor pode concluir a requisição enquanto o navegador impede que JavaScript leia a resposta. Confira Allow-Origin da resposta real e também OPTIONS quando houver preflight.
Qual a diferença entre uma requisição simples e uma com preflight?
Um GET simples segue direto, e a leitura da resposta é verificada depois. POST JSON ou cabeçalhos próprios podem precisar de OPTIONS para autorizar Origin, método e nomes antes da requisição real.
Verificar cabeçalhos CORS aqui envia meus dados a um servidor?
A análise local não transmite cabeçalhos colados. Apenas ao selecionar e executar GET no navegador ele envia uma requisição sem credenciais à URL escolhida.
O CORS protege uma API de requisições maliciosas?
Não. CORS limita o que JavaScript no navegador pode ler; não substitui autenticação e autorização do servidor. Clientes como curl não aplicam essa restrição de leitura.
Por que Access-Control-Allow-Origin: * não funciona junto com credentials: include?
Com credentials: include, o servidor deve retornar a Origin exata e Allow-Credentials: true. O curinga Allow-Origin: * não libera a resposta para o script.
Faltou algum cenário?
Use o verificador CORS com respostas reais
Copie no DevTools a resposta real e, se necessário, OPTIONS. O verificador CORS separa as duas decisões antes de você alterar a configuração do servidor.
Análise local por padrão; GET só após o clique.