O que é CORS?

O Navegador do Agente Sem Raspagem executa sessões de navegador que podem observar como um site se comporta sob as regras de origem cruzada do navegador.

O Compartilhamento de Recursos de Origem Cruzada, ou CORS, é um mecanismo de cabeçalho HTTP que permite que um servidor declare quando um navegador pode expor uma resposta a um script em execução em outra origem. Uma origem é a combinação de esquema, host e porta. O CORS é importante porque uma página carregada de uma origem muitas vezes quer chamar uma API em outra; o navegador restringe essa leitura a menos que a resposta atenda às regras do CORS.

Um erro CORS é fácil de ser mal interpretado como uma falha de rede ou um problema de autenticação da API. A solicitação pode ter chegado ao servidor, e o servidor pode ter retornado dados, enquanto o navegador se recusa a tornar esses dados disponíveis para o script da página. Diagnostique a decisão do navegador separadamente da decisão comercial da API.

O Limite de Origem ao Qual o CORS Se Aplica

Duas URLs compartilham uma origem somente quando seu esquema, host e porta coincidem. Mudar de http para https, mover para um subdomínio ou usar outra porta cria uma origem diferente. Uma página pode fazer algumas solicitações de origem cruzada sem obter acesso ao corpo da resposta. O guia de CORS do MDN descreve isso como um relaxamento controlado da política de mesma origem para solicitações HTTP de origem cruzada feitas por scripts.

O servidor comunica permissão com cabeçalhos de resposta como Access-Control-Allow-Origin. Um navegador compara o valor com a origem da página solicitante. O navegador é o ponto de aplicação para o script da página. Um cliente de linha de comando pode enviar uma solicitação HTTP sem aplicar as regras CORS do navegador, então uma resposta bem-sucedida da linha de comando não prova que uma página da web pode ler o mesmo recurso.

O CORS não é um sistema de autorização. Um servidor ainda deve autenticar chamadores e verificar permissões de recursos. Conceder permissão a uma origem para ler uma resposta é diferente de decidir que um usuário pode visualizar um registro de conta privada. Trate esses como controles separados e teste ambos. Uma configuração CORS permissiva não pode substituir com segurança verificações de acesso do lado do servidor.

Solicitações Simples e Solicitações de Pré-vôo

Para algumas solicitações de origem cruzada, o navegador envia a solicitação real e depois verifica a permissão de resposta. Outras solicitações requerem um pré-vôo: o navegador primeiro envia uma solicitação OPTIONS para perguntar se o método proposto e os cabeçalhos são permitidos. A definição de pré-vôo identifica os campos Origin e Access-Control-Request-Method, com Access-Control-Request-Headers quando necessário.

Uma solicitação com um cabeçalho de autorização personalizado ou um tipo de conteúdo não listado pode acionar o pré-vôo. Se o pré-vôo falhar, o navegador não envia a solicitação real associada. Essa diferença importa durante o diagnóstico. Um log do servidor de aplicativos sem POST ainda pode mostrar uma solicitação OPTIONS, e um desenvolvedor que verifica apenas a rota POST pode perder o ponto de rejeição.

A aprovação do pré-vôo é limitada ao método, cabeçalhos, origem e regras de recurso solicitados. Não significa que a operação comercial posterior será bem-sucedida. A solicitação real ainda pode falhar na autenticação ou validação. Por outro lado, um pré-vôo falhado não é uma evidência de que a API rejeitou os dados do usuário; a solicitação que contém os dados pode nunca ter chegado ao aplicativo.

As Credenciais Mudam as Regras de Resposta

Uma solicitação de origem cruzada pode envolver cookies ou outras credenciais gerenciadas pelo navegador. Quando uma página espera uma resposta credenciada, um valor de Access-Control-Allow-Origin curinga não é suficiente. O servidor deve identificar uma origem permitida e aplicar a regra de resposta de credenciais relevante. O guia de erro de credenciais do MDN explica por que a combinação de curinga e credenciais falha.

O modo de credenciais da solicitação e a política de cookies são entradas separadas. Um navegador pode omitir um cookie devido às configurações SameSite, Secure ou de domínio, mesmo quando os cabeçalhos CORS parecem corretos. Um erro de autenticação pode então aparecer após a verificação do CORS ser bem-sucedida. Inspecione a solicitação e a resposta nas ferramentas de desenvolvedor em vez de alterar os campos CORS para compensar um cookie que nunca foi enviado.

Permitir cada origem solicitante dinamicamente sem validação pode expor respostas sensíveis a páginas não confiáveis. Mantenha uma política de origem explícita para dados que requerem credenciais e assegure-se de que os caches variem apropriadamente quando as respostas dependem da Origem. A revisão de segurança deve incluir o recurso autenticado real, não apenas um endpoint de teste que retorna texto público.

Como Diagnosticar uma Falha de CORS no Navegador

Comece com a origem da página e a origem de destino final, incluindo redirecionamentos. Uma solicitação que redireciona para um host de login pode precisar de uma política diferente da URL da API original. Nas ferramentas de desenvolvedor do navegador, inspecione a troca OPTIONS se existir, a solicitação real se foi enviada e os cabeçalhos de resposta. O catálogo de erros de CORS mapeia mensagens comuns do console para campos de resposta ausentes ou incompatíveis.

Uma chamada fetch falhada pode expor apenas um erro genérico para o JavaScript, enquanto o console contém a razão específica do CORS. Registre ambas as superfícies. Verifique se a resposta carece de Access-Control-Allow-Origin, nomeia uma origem diferente, omite um método ou cabeçalho permitido ou entra em conflito com o modo de credenciais. Faça uma alteração de configuração no servidor que você controla, então teste a mesma página e solicitação novamente.

Não adicione extensões de navegador ou desative verificações de segurança como uma solução de produção. Tal mudança local pode ocultar um defeito de integração enquanto deixa usuários reais bloqueados. Se a API for de terceiros e não permitir a origem da sua página, use uma arquitetura de integração do lado do servidor suportada ou peça ao provedor um caminho de acesso documentado para o navegador.

CORS na Automação de Navegadores e Coleta de Dados

Uma sessão real do navegador executa scripts de página sob as regras de segurança do navegador. Agente de Navegador Scrapeless fornece execução de navegador controlada remotamente, para que uma página que faz solicitações de origem cruzada possa ser observada nesse ambiente. A introdução do Agente de Navegador descreve o produto do navegador. Não transforma uma resposta de API não autorizada em uma autorizada.

Uma solicitação de dados do lado do servidor tem um limite de CORS diferente: o CORS do navegador não governa um cliente HTTP de backend. Outros controles ainda se aplicam, incluindo credenciais do provedor, permissões alvo e políticas de taxa. Escolha o navegador quando precisar testar ou reproduzir o comportamento da própria página. Escolha uma API de servidor documentada quando a tarefa for troca direta de dados e o provedor a suportar.

O guia relacionado de inspeção de rede do navegador discute a observação das solicitações usadas por uma página. A observação não é permissão para usar endpoints privados fora de seu contexto pretendido. Ao revisar um rastreio do navegador, concentre-se nos dados públicos ou explicitamente autorizados necessários para a tarefa e mantenha as credenciais fora dos logs compartilhados.

Uma Lista de Verificação Prática de Decisão CORS

Identifique o proprietário do recurso e a origem da página que o chama. Decida se o script do navegador realmente precisa ler a resposta. Se sim, configure o servidor de recursos para permitir apenas a origem, métodos, cabeçalhos e comportamento de credenciais pretendidos. Se não, mantenha a chamada em um backend controlado onde o navegador nunca precisa de acesso direto à API de terceiros.

Teste o método exato e os cabeçalhos usados em produção. Um GET sem campos personalizados pode funcionar enquanto um POST JSON com um cabeçalho de autorização aciona um pré-vôo. Também teste o caminho de erro: uma resposta de sucesso com cabeçalhos CORS corretos é insuficiente se falhas de autenticação ou redirecionamentos os omitirem. Os usuários do navegador precisam que a falha real seja visível e diagnosticável.

Por fim, separando três observações em notas de incidentes: se a solicitação de rede foi feita, se o servidor aceitou a operação e se o navegador expôs a resposta ao script da página. Essas respostas podem ser diferentes. Mantê-las distintas evita que um problema de política de navegador seja “resolvido” enfraquecendo a autorização do servidor não relacionada.

Conclusão

CORS permite que um servidor de recursos especifique quais outras origens podem ler suas respostas de scripts de navegador. Seu efeito depende da origem da página, forma da solicitação, pré-vôo e modo de credenciais. Diagnostique essas partes no navegador enquanto mantém intactas as verificações de autenticação e permissões do lado do servidor.