VoriTools

Analisador de cabeçalhos CORS

Preencha os dados da requisição. Nenhuma chamada é enviada; o servidor e as restrições de valores precisam de testes separados.

Funciona localmente no seu navegador
Ver categoria: Desenvolvimento de API (15)
Esta ferramenta processa todos os dados localmente no seu navegador.
Solicitação do navegador e cabeçalhos de resposta copiadosEste verificador apenas modela regras do navegador; não contata a API nem reproduz credenciais.

Modelar uma solicitação CORS do navegador com cabeçalhos de resposta copiados

Este analisador modela uma solicitação CORS do navegador com os cabeçalhos de resposta que você colar. Ele responde a uma única pergunta: o navegador deixaria a página ler essa resposta e o preflight, quando existe, seria aceito?

Tudo roda na aba. Nenhuma solicitação é enviada, então o resumo descreve o que os cabeçalhos copiados permitem, não o que o servidor real devolve hoje.

  1. Informe a origem da solicitação (esquema, host, porta) e escolha o método. PUT, PATCH e DELETE exigem preflight; GET, HEAD e POST normalmente não.
  2. Liste os cabeçalhos que o navegador colocaria em Access-Control-Request-Headers, por exemplo Authorization, X-Request-ID, e marque credenciais quando a solicitação enviar cookies ou autenticação HTTP.
  3. Cole o bloco completo de cabeçalhos de resposta em linhas `Nome: valor` e clique em Analisar política CORS.
  4. Leia primeiro a decisão e depois as verificações: cada linha indica o cabeçalho que permitiu ou bloqueou a solicitação. Copie ou baixe o resumo para guardar.

Como o analisador lê os cabeçalhos Access-Control e onde ele para

Correspondência de origem e credenciais

O Access-Control-Allow-Origin precisa repetir a origem exata da solicitação: esquema e host em minúsculas, portas padrão omitidas e sem barra no final. O Chrome rejeita `https://app.example.com/` para a origem `https://app.example.com`, e o analisador informa a mesma divergência.

`*` libera qualquer origem apenas quando a solicitação não envia credenciais. Com cookies ou autenticação HTTP a resposta precisa repetir a origem e adicionar `Access-Control-Allow-Credentials: true`; a origem curinga é bloqueada mesmo parecendo permissiva.

O que exige preflight e o que passa sem ele

Um Content-Type JSON ou qualquer cabeçalho personalizado fazem o navegador enviar um preflight OPTIONS antes da solicitação. O Chrome então exige entrada correspondente em Access-Control-Allow-Methods e em Access-Control-Allow-Headers para cada cabeçalho listado; sem elas a resposta é bloqueada, enquanto `text/plain` na mesma política passa.

GET, HEAD e POST são métodos da lista segura: passam o preflight mesmo que Access-Control-Allow-Methods não os liste. PUT, PATCH e DELETE precisam aparecer. Nomes de método e de cabeçalho são comparados sem diferenciar maiúsculas: `post` e `x-test` coincidem.

Curingas que param de valer com credenciais

`Access-Control-Allow-Methods: *` e `Access-Control-Allow-Headers: *` só são curingas para solicitações sem credenciais. Uma solicitação com credenciais precisa do método e de cada cabeçalho listados literalmente, e o analisador agora informa isso em vez de confiar no asterisco.

O que o analisador não faz: não envia a solicitação nem repete credenciais, não julga restrições de valor de cabeçalho (um esquema de Authorization, um valor de Content-Type) e não cobre redirecionamentos, origens nulas, Access-Control-Expose-Headers, Max-Age ou Vary.

Ferramentas recentes: