O CORS (Cross-Origin Resource Sharing) controla se um site pode chamar uma API de outra origem. Esta ferramenta simula essa verificação do navegador e explica-te, sem fazer nenhum pedido real, se o teu servidor permitiria a chamada.
Preenche a Origem (o URL da app que faz o pedido), o Método HTTP (GET, POST, PUT…) e cola os headers de resposta do teu servidor, um por linha (por exemplo Access-Control-Allow-Origin: *).
Há duas formas de pedido cross-origin:
• Pedido simples — com GET, POST ou HEAD e cabeçalhos básicos, o navegador envia-o diretamente e depois verifica se a resposta traz Access-Control-Allow-Origin.
• Com preflight — com métodos como PUT, PATCH ou DELETE (ou cabeçalhos personalizados), o navegador envia antes um pedido prévio do tipo OPTIONS para pedir permissão. A ferramenta assinala automaticamente quando o seu método requer preflight.
Alguns métodos e headers obrigam o navegador a enviar antes um pedido preflight com o método OPTIONS. Se a ferramenta o detetar, o teu servidor deve responder a esse OPTIONS com os headers CORS adequados.
É o cabeçalho imprescindível: indica que origem pode ler a resposta.
• * — permite qualquer origem, mas não funciona com credenciais (cookies).
• Uma origem concreta, p. ex. https://myapp.com — só essa origem, e tem de coincidir exatamente com a sua Origem (protocolo + domínio + porta).
Se faltar este cabeçalho, ou o valor não coincidir com * nem com a sua origem, o pedido é bloqueado.
Lista os métodos HTTP que o servidor aceita de outra origem, separados por vírgulas (p. ex. GET, POST, PUT, DELETE). É relevante sobretudo no preflight. Se indicar este cabeçalho mas não incluir o seu método, a ferramenta assinala-o como problema e bloqueia o pedido. Se não o colocar, o método não é verificado.
Enumera que cabeçalhos de pedido o cliente pode enviar (p. ex. Content-Type, Authorization). O navegador exige-o no preflight quando o seu pedido envia cabeçalhos não padrão. Se a sua app enviar Authorization e aqui não aparecer, o navegador bloqueará a chamada.
Com valor true permite enviar cookies e credenciais no pedido cross-origin.
• Atenção, gotcha importante: as credenciais são incompatíveis com Access-Control-Allow-Origin: *. Se usar credenciais, a origem tem de ser específica (p. ex. https://myapp.com), nunca *. Combinar ambos faz com que o navegador rejeite a resposta.
Access-Control-Max-Age indica quantos segundos o navegador pode guardar em cache a resposta do preflight (p. ex. 86400 = 24 h), para não repetir o OPTIONS em cada chamada. A ferramenta inclui-o nos headers sugeridos quando o seu método precisa de preflight. Lembre-se ainda de adicionar Vary: Origin no seu servidor quando devolver uma origem concreta, para que as caches não misturem respostas de origens diferentes.
O banner indica se o pedido está permitido ou bloqueado e porquê. Por baixo, explica-se cada header CORS detetado, listam-se os problemas encontrados e propõe-se um bloco de headers sugeridos pronto a copiar para o teu servidor.
Access-Control-Allow-Origin*Permite cualquier origen (no funciona con credenciales)Access-Control-Allow-MethodsGET, POSTMétodos permitidos: GET, POSTAccess-Control-Allow-Origin: https://myapp.com Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS Access-Control-Allow-Headers: Content-Type, Authorization