Testador de CORS
Erros de CORS são o vermelho “clássico” do console do navegador: você acessa uma API de uma origem diferente e o navegador bloqueia a resposta. Este testador envia uma solicitação OPTIONS de pré-verificação para qualquer URL que você colar, com a origem e o método escolhidos, e decodifica os cabeçalhos Access-Control-* para que você veja exatamente o que o servidor está permitindo, o que está bloqueando e por que o navegador reclama.
Como testar CORS
-
1
Insira a URL de destino
O endpoint da API que você deseja chamar do seu front-end. Inclua a string de consulta e o protocolo.
-
2
Defina o método e a origem
GET/POST/PUT/DELETE/PATCH. A origem pode ser a URL do seu site ou qualquer origem que você queira simular.
-
3
Entenda a pré-verificação
O testador sempre envia uma solicitação OPTIONS com a origem e o método escolhidos, mais o cabeçalho Access-Control-Request-Headers: Content-Type, exatamente a pré-verificação que um navegador envia antes de uma solicitação JSON.
-
4
Execute o teste
O testador envia a pré-verificação e relata o status HTTP mais os cabeçalhos de resposta CORS: Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials e Max-Age.
-
5
Corrija a configuração incorreta
O relatório sinaliza o que está faltando ou errado, Allow-Origin ausente, cabeçalho proibido, método não permitido.
Os cabeçalhos que importam
| Cabeçalho | O que faz |
|---|---|
| Access-Control-Allow-Origin | Quais origens podem ler a resposta |
| Access-Control-Allow-Methods | Prévia: quais métodos são permitidos |
| Access-Control-Allow-Headers | Prévia: quais cabeçalhos de solicitação são permitidos |
| Access-Control-Allow-Credentials | Se cookies/auth são permitidos |
| Access-Control-Expose-Headers | Quais cabeçalhos de resposta o JS pode ler |
| Access-Control-Max-Age | Quanto tempo o resultado da prévia é armazenado |
Solicitações simples vs. prévias
Uma solicitação é “simples” (sem prévia) apenas se todas essas condições forem verdadeiras:
- O método é GET, HEAD ou POST.
- Os cabeçalhos são limitados a Accept, Accept-Language, Content-Language, Content-Type (com valores específicos).
- Content-Type, se presente, é application/x-www-form-urlencoded, multipart/form-data ou text/plain.
Qualquer outra coisa, um corpo JSON, um cabeçalho Authorization, um cabeçalho personalizado X-Foo, um PUT/DELETE/PATCH, aciona uma prévia OPTIONS. Os servidores devem responder à prévia com os cabeçalhos Allow-* corretos ou a solicitação real nunca é enviada.
Falhas comuns de CORS
- “Cabeçalho Access-Control-Allow-Origin ausente” → o servidor não define o cabeçalho. Corrija no servidor, não no cliente.
- “O modo de credenciais requer Allow-Origin não sendo *” → se você enviar cookies,
Allow-Origindeve ser uma origem específica (ou ecoar o cabeçalho Origin). - “Cabeçalho de solicitação X não permitido” → adicione X a
Access-Control-Allow-Headersna resposta da prévia. - “Método não permitido” → adicione o método a
Access-Control-Allow-Methods. - “Redirecionamento não permitido na prévia” → a prévia não pode seguir redirecionamentos. O endpoint OPTIONS deve responder diretamente.
Allow-Origin: * vs. ecoando Origin
Access-Control-Allow-Origin: * é permissivo, mas não pode ser combinado com credenciais. Em produção, ecoe a Origin da solicitação de volta (após validar contra uma lista de permissões) e defina Allow-Credentials: true se precisar de cookies.
Proxy como uma solução alternativa
Se você não pode controlar o servidor, um proxy leve em seu próprio domínio remove completamente o CORS, o navegador vê a mesma origem. Muitas plataformas de hospedagem (Vercel, Netlify, Cloudflare) oferecem regras de reescrita exatamente para isso.
Perguntas frequentes
Para evitar que uma página maliciosa leia dados privados em outro site usando os cookies do seu navegador. Sem CORS, visitar evil.com poderia permitir que ele solicitasse a API interna do seu banco como você. O CORS força o banco a permitir explicitamente leituras de origem cruzada.
Apenas em desenvolvimento. O Chromium tem uma flag --disable-web-security, mas isso afeta todos os sites e é perigoso. A correção correta são cabeçalhos do lado do servidor ou um proxy.
O Postman não é um navegador, ele ignora completamente o CORS. O CORS é aplicado apenas pelos navegadores para solicitações JavaScript. Um servidor que funciona no Postman não é automaticamente correto em relação ao CORS.
Imagens e tags <script> clássicas carregam de origem cruzada sem CORS, mas o JS não pode ler seu conteúdo. <img crossorigin> e fetch() aplicam CORS, razão pela qual imagens desenhadas em canvas ficam “contaminadas” sem isso.
Ferramentas relacionadas
Consulta DNS
Consulte os registros DNS A, AAAA, MX, TXT, NS, CNAME e SOA de qualquer domínio sem abrir um terminal.
Consulta de endereço IP
Consulte um endereço IPv4 ou IPv6 público para ver país, região, cidade, coordenadas, ISP, ASN, organização e fuso horário aproximados.
Consulta WHOIS
Consulte dados WHOIS públicos de um domínio: registrador, servidores DNS, códigos de status e datas de expiração.
Analisador de cabeçalhos de e-mail
Analise cabeçalhos de e-mail no navegador. Confira saltos Received, tempos e dados SPF, DKIM, DMARC e ARC sem enviar a mensagem.
Consulta DNS reversa
Consulte o registro PTR de um endereço IPv4 ou IPv6. Útil para depurar servidores de email, analisar logs e investigar filtros antispam.
Verificador de Endpoint de API
Teste no navegador um endpoint HTTP ou HTTPS com CORS. Confira o status final, os cabeçalhos expostos, o tempo e uma prévia limitada do corpo.