Rede/HTTP
CORS Checker / Explainer
Explicar passo a passo se o navegador permitirá uma requisição cross-origin — classificação simple/preflight, verificação dos cabeçalhos Access-Control-* da resposta, resumo.
Um por linha, "Nome" ou "Nome: valor" — o valor não afeta a classificação.
Pegue na aba Network do DevTools (cabeçalhos da própria resposta ou do preflight OPTIONS) ou com curl -I.
CORS (Cross-Origin Resource Sharing) is a browser mechanism that decides whether JavaScript from one site is allowed to read a response from a server on a different domain. This tool walks through, step by step, whether a specific request will succeed and which Access-Control-* headers it needs.
How to use it
- Provide the method, the request's origin, and the server's response headers (Access-Control-Allow-Origin, etc.) and the tool determines whether the browser will let the request through.
- The "simple" vs. "preflight" classification shows whether the browser will first send an OPTIONS preflight request before the actual one.
- The summary gives the exact reason for a failure when a request would be blocked — faster than parsing the browser console's error message.
Common uses
- Debugging the classic "has been blocked by CORS policy" error with a step-by-step explanation of what's missing, instead of guessing.
- Checking a backend's CORS configuration before the frontend and API end up on separate domains in production.
- Understanding why a request with credentials: include is rejected even though Access-Control-Allow-Origin looks correct.
Things to keep in mind
CORS protects the user's browser, not the server — the restriction only applies to requests made from page JavaScript in a browser, not to requests from curl, Postman, or server-to-server calls.
Access-Control-Allow-Origin: * is incompatible with credentials: include — for requests carrying cookies or authorization, the server must return a specific origin instead of a wildcard.
Perguntas frequentes
Por que uma requisição falha com erro de CORS mesmo que o servidor tenha respondido com sucesso?
O CORS é aplicado pelo navegador, não pelo servidor — se a resposta não tiver um cabeçalho Access-Control-Allow-Origin correspondente à origem solicitante, o navegador bloqueia o JavaScript de ler a resposta, mesmo que a requisição em si tenha sido concluída.
Qual a diferença entre uma requisição simples e uma com preflight?
Requisições simples (GET/POST básicos com cabeçalhos padrão) passam diretamente, enquanto requisições com cabeçalhos personalizados, outros métodos ou certos tipos de conteúdo disparam primeiro uma requisição preflight OPTIONS para verificar permissão antes de enviar a requisição real.
Verificar cabeçalhos CORS aqui envia meus dados a um servidor?
A ferramenta inspeciona cabeçalhos que você fornece ou busca diretamente do seu navegador — nenhum servidor intermediário armazena os dados da sua requisição.
O CORS protege uma API de requisições maliciosas?
Não. O CORS restringe apenas o que o JavaScript no navegador pode ler — um invasor usando curl, Postman ou um script backend o ignora completamente, então autenticação e autorização reais devem ser implementadas no servidor.
Por que Access-Control-Allow-Origin: * não funciona junto com credentials: include?
A especificação proíbe essa combinação deliberadamente por segurança: permitir credentials (cookies, cabeçalhos de autorização) junto com um curinga que aceita qualquer origem seria uma falha de segurança grave, então o servidor deve retornar uma origem exata ao usar credentials.