Compreender o Funcionamento do Verificador CORS
O Cross-Origin Resource Sharing (CORS) é um mecanismo de segurança essencial que os navegadores web utilizam para restringir a forma como os scripts executados numa página web interagem com recursos de outra origem. O Verificador CORS ajuda a diagnosticar e prever se um navegador web permitiria ou bloquearia um pedido específico de origem cruzada, analisando os cabeçalhos de resposta HTTP fornecidos e os detalhes do pedido simulado.
Esta ferramenta é útil para programadores de front-end, programadores de back-end, programadores de plataformas de API e engenheiros de operações que precisam de compreender se o código do navegador consegue ler uma resposta específica ou se uma resposta OPTIONS de pré-verificação aprova um método posterior e os cabeçalhos solicitados.
O processamento é feito localmente: os seus cabeçalhos e detalhes do pedido permanecem no seu navegador. Nada é carregado ou guardado pelo BroBroGo.
Configuração dos Dados de Entrada
Para avaliar a política CORS, deve configurar os seguintes campos no utilitário:
- Resposta à verificação: Escolha entre "Resposta real" (para verificar se o código do navegador consegue ler uma resposta) ou "Resposta de pré-verificação" (para analisar a resposta
OPTIONSque aprova um método posterior e os cabeçalhos solicitados). - HTTP cabeçalhos de resposta: O bloco de texto contendo os cabeçalhos HTTP retornados pelo servidor. Se estiver a verificar uma resposta de pré-verificação, deve incluir também a linha de estado HTTP. O limite máximo para esta entrada é de 200 000 caracteres.
- Origem do pedido: O esquema, o host e a porta opcional que representam a origem de onde o pedido parte (por exemplo,
https://app.example.com). Não são permitidos caminhos de URL, parâmetros de consulta ou credenciais neste campo. - Método solicitado: O método HTTP que o pedido utiliza ou pretende utilizar (como
GET,POST,PUT, etc.). - Nomes de cabeçalhos solicitados: Os cabeçalhos que o cliente pretende enviar, correspondentes ao cabeçalho
Access-Control-Request-Headers. Podem ser inseridos separados por vírgulas ou por linhas. - Inclua credenciais: Um interruptor para indicar se o pedido inclui cookies ou autenticação HTTP.
Validações e Mensagens de Erro de Entrada
Durante a introdução de dados, a ferramenta valida a conformidade técnica dos valores inseridos. Se existirem problemas, será exibida a mensagem "Corrige a entrada destacada e tenta novamente." juntamente com erros específicos:
- Se o campo de cabeçalhos estiver vazio: "Cole os cabeçalhos de resposta HTTP antes de verificar.".
- Se o tamanho dos cabeçalhos exceder o limite: "Esta resposta é invulgarmente grande. Mantém
‹max›personagens.". - Se uma linha de cabeçalho for inválida: "A linha
‹line›não é um cabeçalho de HTTP ou linha de estado válida.". - Se o nome de um cabeçalho for inválido: "A linha
‹line›contém um nome de cabeçalho de HTTP inválido.". - Se a origem do pedido contiver caminhos ou elementos inválidos: "Introduza uma origem apenas com um esquema, anfitrião e porta opcional, como https://app.example.com.".
- Se o método HTTP for inválido: "Introduza um token válido do método HTTP.".
- Se o método for proibido para pedidos de busca: "Os navegadores não permitem o método
‹method›em pedidos de busca.". - Se um cabeçalho solicitado for inválido: ""
‹header›" não é um nome válido de cabeçalho HTTP pedido.".
Regras de Avaliação e Decisões do Navegador
O motor de análise aplica as regras oficiais do protocolo CORS para determinar o resultado. A tabela abaixo resume os cenários de decisão e as respetivas justificações técnicas apresentadas pela ferramenta:
| Decisão do Navegador | Razão Apresentada | Contexto Técnico |
|---|---|---|
| Permitido pela resposta CORS colada. | Access-Control-Allow-Origin corresponde exatamente ‹origin›. |
O cabeçalho Access-Control-Allow-Origin coincide com a origem do pedido. |
| Access-Control-Allow-Origin permite qualquer origem para este pedido. | O cabeçalho contém o wildcard * e o pedido não inclui credenciais. |
|
| Access-Control-Allow-Credentials é exatamente verdade. | O pedido inclui credenciais e o cabeçalho Access-Control-Allow-Credentials está definido como true. |
|
| As credenciais não estão incluídas, por isso Access-Control-Allow-Credentials não afeta esta decisão. | O pedido não envia cookies ou autenticação, ignorando a necessidade deste cabeçalho. | |
O ‹status› de estado pré-voo é bem-sucedido. |
A resposta de pré-verificação contém um código de estado HTTP 2xx válido. | |
O pré-voo permite ‹method›. |
O método solicitado está presente em Access-Control-Allow-Methods. |
|
‹method› é um método CORS na lista segura e não precisa de aparecer em Access-Control-Allow-Methods. |
Métodos como GET ou POST (sob certas condições) estão na lista segura. |
|
| Nenhum nome de cabeçalho solicitado necessita de aprovação pré-voo. | Os cabeçalhos do pedido pertencem à lista segura padrão. | |
O pré-voo permite os nomes de cabeçalhos solicitados: ‹headers›. |
Os cabeçalhos solicitados estão explicitamente listados em Access-Control-Allow-Headers. |
|
Access-Control-Allow-Headers: * cobre estes nomes para um pedido sem credenciais: ‹headers›. |
O wildcard * é válido para cabeçalhos quando não há credenciais envolvidas. |
|
| Bloqueado pela resposta colada CORS. | Access-Control-Allow-Origin está desaparecido. | Falta o cabeçalho obrigatório Access-Control-Allow-Origin. |
| Access-Control-Allow-Origin não pode ser * quando as credenciais estão incluídas. | Restrição de segurança que proíbe wildcards na origem quando se usam credenciais. | |
Access-Control-Allow-Origin é ‹actual›, não ‹expected›. |
A origem permitida pelo servidor não coincide com a origem do pedido. | |
Access-Control-Allow-Origin tem um valor inválido: ‹value›. |
O valor do cabeçalho é inválido (por exemplo, contém múltiplas origens ou valores separados por vírgulas). | |
| Um pedido credenciado precisa Access-Control-Allow-Credentials: verdade. | O pedido inclui credenciais, mas o cabeçalho necessário está em falta ou não é true. |
|
O estado pré-voo ‹status› não é um estado 2xx bem-sucedido. |
A resposta de pré-verificação falhou com um código de erro HTTP. | |
Access-Control-Allow-Methods não permite ‹method›. |
O método solicitado não está autorizado na resposta de pré-verificação. | |
Access-Control-Allow-Headers não permite: ‹headers›. |
Um ou mais cabeçalhos solicitados não foram autorizados pelo servidor. | |
| Authorization deve ser listado explicitamente; Access-Control-Allow-Headers: * não cobre. | O cabeçalho Authorization exige sempre declaração explícita, mesmo com o uso de *. |
|
| Os headers passam, mas o estado pré-voo é desconhecido. | Não foi colada nenhuma linha de estado HTTP, pelo que o estado pré-voo 2xx exigido não pode ser verificado. | A resposta de pré-verificação carece da linha de estado HTTP para validação completa. |
Limitações do Diagnóstico Estático
Este utilitário analisa exclusivamente os cabeçalhos de resposta e os detalhes do pedido fornecidos manualmente. A ferramenta não realiza as seguintes operações:
- Não contacta servidores externos.
- Não lê URLs diretamente da internet.
- Não define cookies nem interage com o armazenamento local.
- Não verifica configurações de DNS ou certificados TLS.
- Não modifica configurações de servidores.
Um resultado positivo nesta ferramenta significa apenas que os dados colados cumprem as regras de CORS. Não garante que o pedido em tempo real funcione no ambiente de produção, uma vez que fatores externos como redirecionamentos de rede, respostas em cache, alterações dinâmicas nas regras do servidor, extensões do navegador ou a resposta real obtida após o pré-voo podem alterar o comportamento final do navegador.
Perguntas Frequentes
Devo colar a resposta real ou a resposta pré-voo?
Use Resposta Real para verificar se o código do navegador pode ler uma resposta. Use a resposta Preflight para a resposta OPTIONS que aprova um método posterior e os nomes dos cabeçalhos solicitados.
Porque é que um wildcard pode falhar com credenciais?
Quando são incluídos cookies ou autenticação HTTP, a origem permitida deve corresponder exatamente à origem que solicita. Os wildcards para métodos permitidos e cabeçalhos também perdem o seu significado de wildcard.
Um resultado de aprovação prova que o pedido em tempo real vai funcionar?
Não. Este resultado cobre apenas a resposta colada e os detalhes do pedido inseridos aqui. Redirecionamentos, respostas em cache, alterações nas regras do servidor, extensões do navegador e a resposta real após um pré-voo ainda podem alterar o resultado.