Entendendo a Política de CORS no Navegador
O Compartilhamento de Recursos de Origem Cruzada (CORS) é um mecanismo de segurança essencial implementado pelos navegadores web para controlar como scripts executados em uma origem podem interagir com recursos de outra origem. Uma origem é definida pela combinação de esquema (protocolo), host e porta. Quando uma aplicação web tenta fazer uma requisição para um domínio diferente, o navegador avalia os cabeçalhos HTTP da resposta para determinar se a leitura dos dados ou a execução do método solicitado é permitida.
Esta ferramenta analisa os cabeçalhos de resposta fornecidos e os parâmetros da requisição para simular exatamente como um navegador processaria essa transação. O processamento ocorre localmente: seus cabeçalhos e detalhes das solicitações permanecem no seu navegador, e nada é enviado ou salvo pelo BroBroGo.
Configuração de Entradas para Verificação
Para validar a política de CORS, a ferramenta exige a definição precisa dos dados da requisição e da resposta. Os campos de entrada configuráveis são:
- Resposta à verificação: Escolha entre "Resposta real" (para verificar se o código do navegador pode ler uma resposta) ou "Resposta de pré-verificação" (para validar a resposta de uma requisição
OPTIONSprévia). - HTTP cabeçalhos de resposta: O bloco de texto contendo os cabeçalhos retornados pelo servidor, com limite máximo de 200.000 caracteres. Para respostas de pré-verificação, inclua também a linha de status HTTP.
- Origem do pedido: O esquema, host e porta opcional de onde a requisição parte (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 da requisição (como
GET,POSTouPUT). - Nomes de cabeçalhos solicitados: Cabeçalhos personalizados que a requisição pretende enviar, correspondentes ao cabeçalho
Access-Control-Request-Headers. Eles podem ser separados por vírgulas ou quebras de linha. - Inclua credenciais: Um seletor para indicar se a requisição carrega cookies ou dados de autenticação HTTP.
O Papel dos Cabeçalhos de Controle de Acesso
A decisão do navegador baseia-se na presença e nos valores de cabeçalhos HTTP específicos iniciados por Access-Control-.
Access-Control-Allow-Origin
Este cabeçalho indica quais origens têm permissão para acessar o recurso. Ele pode conter uma origem exata ou o caractere curinga *. Se o cabeçalho estiver ausente, a requisição é bloqueada. Caso contenha múltiplos valores separados por vírgula, o cabeçalho é considerado inválido pelo navegador.
Access-Control-Allow-Credentials
Quando a requisição inclui credenciais (como cookies), o navegador exige obrigatoriamente que o cabeçalho Access-Control-Allow-Credentials esteja presente com o valor exato true. Se as credenciais não forem incluídas na requisição, a presença ou ausência deste cabeçalho não afeta a decisão.
O Impacto de Credenciais sobre Curingas
O uso de credenciais altera drasticamente as regras de validação de curingas (*):
- O cabeçalho
Access-Control-Allow-Originnão pode ser*se as credenciais estiverem inclusas. A origem deve ser declarada de forma explícita e idêntica à origem solicitante. - Os curingas para métodos (
Access-Control-Allow-Methods) e cabeçalhos (Access-Control-Allow-Headers) perdem sua função de correspondência universal quando a requisição é credenciada.
Requisições de Pré-Verificação (Preflight)
Requisições que não são classificadas como simples exigem uma verificação prévia do tipo OPTIONS, conhecida como preflight. O navegador utiliza essa etapa para validar se o método e os cabeçalhos personalizados são aceitos pelo servidor antes de enviar a requisição real.
Validação de Métodos e Cabeçalhos
- Métodos: Se o método solicitado não estiver na lista segura do CORS (CORS-safelisted), ele deve ser explicitamente autorizado pelo cabeçalho
Access-Control-Allow-Methods. - Cabeçalhos: Cabeçalhos personalizados devem ser autorizados por
Access-Control-Allow-Headers. Se a requisição não contiver credenciais, o uso deAccess-Control-Allow-Headers: *cobre os cabeçalhos solicitados, com uma exceção importante: o cabeçalhoAuthorizationdeve ser listado explicitamente, pois o curinga*não o abrange.
Importância do Status HTTP no Preflight
Para que uma resposta de pré-verificação seja considerada válida, ela deve retornar um código de status HTTP de sucesso na faixa 2xx. Se nenhum cabeçalho de status HTTP for colado na ferramenta durante a análise de uma resposta de pré-verificação, o status exigido não poderá ser validado, resultando em um estado indeterminado.
Limitações da Análise Estática
Esta ferramenta realiza uma validação lógica baseada estritamente nos cabeçalhos e parâmetros fornecidos pelo usuário. Ela não realiza conexões de rede com servidores externos, não lê URLs ativas, não define cookies, não verifica registros de DNS ou certificados TLS, e não altera configurações de servidores.
Um resultado positivo indica apenas que os dados inseridos estão em conformidade com as regras de CORS do navegador. Ele não garante que uma requisição real funcionará, pois fatores externos como redirecionamentos de rede, políticas de cache, regras dinâmicas do servidor, extensões instaladas no navegador ou modificações na resposta real após o preflight podem interferir no comportamento final da aplicação.
Perguntas Frequentes
Devo colar a resposta real ou a resposta pré-voo?
Use a 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.
Por que um coringa pode falhar com credenciais?
Quando cookies ou autenticação HTTP são incluídos, a origem permitida deve corresponder exatamente à origem solicitante. Os curingas para métodos permitidos e cabeçalhos também perdem seu significado de coringa.
Um resultado aprovado prova que a solicitação ao vivo vai funcionar?
Não. Este resultado cobre apenas a resposta colada e os detalhes do pedido inseridos aqui. Redirecionamentos, respostas em cache, mudanças nas regras do servidor, extensões do navegador e a resposta real após um pré-voo ainda podem alterar o resultado.
O que acontece se o cabeçalho Access-Control-Allow-Origin contiver múltiplas origens?
O navegador considera o cabeçalho inválido se ele contiver múltiplos valores ou for separado por vírgulas, bloqueando a requisição de origem cruzada.
O cabeçalho Authorization é coberto pelo caractere curinga nos cabeçalhos permitidos?
Não. O cabeçalho Authorization deve ser listado explicitamente no retorno do servidor; o uso de Access-Control-Allow-Headers: * não é suficiente para autorizá-lo.