O que é CORS? Acesso Cross-Origin do Navegador Explicado
A API de Scraping Universal sem Raspagem recupera conteúdo web público permitido e pode renderizar JavaScript quando o CORS deve ser respeitado em uma resposta real.
TL;DR
- CORS tem um papel preciso no protocolo. O Compartilhamento de Recursos Cross-Origin, ou CORS, é um mecanismo de cabeçalho HTTP que permite a um servidor informar a um navegador quais outras origens podem ler uma resposta através de solicitações dirigidas por script.
- CORS deve ser lido na camada correta. Transporte, representação, política do navegador e autorização da aplicação permanecem preocupações separadas.
- Intermediários podem mudar o que uma aplicação observa. Gateways, caches, padrões do navegador e bibliotecas de cliente podem adicionar processamento entre bytes de origem e dados analisados.
- A validação precisa de evidências de conteúdo. Um status ou campo isolado não prova que a representação pública esperada chegou.
- A segurança depende do escopo e da validação. A sintaxe do protocolo nunca concede permissão para acessar um recurso ou confiar em um valor fornecido pelo chamador.
O que é CORS?
O Compartilhamento de Recursos Cross-Origin, ou CORS, é um mecanismo de cabeçalho HTTP que permite a um servidor informar a um navegador quais outras origens podem ler uma resposta através de solicitações dirigidas por script. Uma origem é definida por esquema, host e porta. O CORS relaxa a política de mesma origem do navegador para respostas aprovadas; ele não autentica usuários, autoriza ações comerciais ou impede que clientes não navegadores enviem solicitações HTTP.
A definição útil inclui tanto o mecanismo quanto seu limite. O CORS afeta uma parte específica de uma troca, enquanto responsabilidades adjacentes permanecem com o HTTP, o navegador, o transporte selecionado, a aplicação ou o modelo de dados do servidor. Manter essas camadas separadas torna os relatórios de erro reproduzíveis e evita que uma alteração de configuração seja confundida com uma decisão de controle de acesso.
Para desenvolvedores de API, a primeira pergunta é quem cria o valor ou comportamento. A próxima pergunta é quem o interpreta. A pergunta final é que resultado observável prova que a interpretação funcionou. Essas três respostas transformam um termo de glossário em um contrato de interface testável.
Como um Navegador Toma uma Decisão de CORS
O script da página chama fetch ou XMLHttpRequest para uma URL cuja origem difere da origem da página. O navegador adiciona um campo de Origem que identifica a origem do chamador. Para algumas solicitações, ele envia a solicitação real diretamente; para outras, primeiro envia um pré-vôo OPTIONS que descreve o método pretendido e campos não listados como seguros.
O servidor avalia a origem e retorna campos de resposta de controle de acesso. Access-Control-Allow-Origin nomeia a origem permitida ou, em casos não credenciados elegíveis, usa um curinga. Outros campos podem permitir métodos, campos de solicitação, credenciais ou campos de resposta selecionados que o script da página pode ler.
O navegador compara a resposta com o contexto da solicitação. Se a política não corresponder, o script é bloqueado de ler a resposta protegida, mesmo que o servidor possa ter processado a solicitação HTTP. Essa distinção explica por que um console mostra um erro de CORS enquanto os logs do servidor mostram uma solicitação entrante.
Solicitações credenciadas têm regras mais rígidas. Uma origem curinga não pode ser usada com credenciais do navegador, e o servidor deve permitir explicitamente as credenciais. As regras de Cookie SameSite e a autorização da aplicação ainda se aplicam de forma independente.
Os Campos CORS que Definem Permissão
Os seguintes termos separam os componentes que muitas vezes são condensados em um único rótulo. Leia-os como interfaces entre os participantes e não como decoração em uma captura de rede.
Origem
Identifica o esquema, host e porta da página solicitante; os navegadores o anexam em solicitações cross-origin relevantes.
Access-Control-Allow-Origin
Nomeia a origem cujo script pode ler a resposta ou usa um curinga onde as regras de credencial permitem.
Access-Control-Allow-Methods
Lista métodos aprovados para o contexto de solicitação pré-vôo.
Access-Control-Allow-Headers
Lista nomes de campos de solicitação não aprovados que o servidor permite.
Access-Control-Allow-Credentials
Permite credenciais do navegador na troca cross-origin real quando as regras de origem explícita também são aceitas.
Access-Control-Expose-Headers
Torna campos de resposta selecionados legíveis para o script da página além dos campos de resposta listados como seguros.
Por que CORS é Importante na Coleta de Dados da Web
O CORS pode mudar quais bytes chegam, como esses bytes são interpretados ou se o código do navegador pode observar o resultado. Um fluxo de trabalho de coleta deve localizar esse efeito antes de mudar de ferramentas. Registre a URL solicitada, a URL final, o status da resposta, o tipo de representação, campos de protocolo relevantes e um marcador de conteúdo esperado. Esse registro compacto distingue uma página correta de uma mensagem de acesso, tela de consentimento, alvo de redirecionamento, shell de aplicação vazio ou codificação incompatível.
HTTP direto é o caminho de aquisição mais simples quando os dados necessários existem em uma resposta renderizada por servidor aberta. Um navegador se torna relevante quando o conteúdo aprovado depende da execução de JavaScript, estado gerenciado pelo navegador, navegação ou política de segurança do navegador. Os dois caminhos não devem ser forçados a parecer idênticos: os navegadores gerenciam cookies, compressão, redirecionamentos, CORS e armazenamento de acordo com as regras da plataforma, enquanto um cliente direto expõe um conjunto diferente de padrões.
A continuidade da sessão é importante sempre que uma resposta estabelece uma condição para a próxima solicitação. Mantenha uma sequência autorizada dentro de um contexto de cliente limitado, preserve o local e a origem da rede necessários e evite misturar estado de trabalhos não relacionados. Um proxy muda a origem da rede; ele não reproduz cabeçalhos, decodifica representações, executa scripts ou concede acesso a conteúdo restrito.
A análise começa apenas após a validação da representação. Confirme o host final, identidade canônica onde disponível, tipo de mídia, estado de decodificação e marcador de negócio necessário antes de extrair campos. Essa ordem evita que um analisador transforme um documento de erro em registros vazios que parecem tecnicamente bem-sucedidos.
Intermediários merecem atenção explícita. Uma rede de entrega de conteúdo pode selecionar uma variante codificada, um gateway pode responder a OPTIONS, um cache pode reutilizar uma resposta negociada e um servidor de aplicativos pode definir cookies ou campos de autorização. Comparar apenas o código do aplicativo com a saída da página final ignora a camada que pode ter tomado a decisão.
A API de Scraping Universal sem Duplicação é relevante quando uma equipe precisa de recuperação gerenciada de conteúdo público permitido, incluindo páginas renderizadas em JavaScript. O contrato de aquisição ainda deve definir o alvo, campos permitidos, representação esperada, marcador de aceitação e condições de parada. A capacidade do produto não substitui os termos de origem, a revisão de privacidade ou a validação em nível de aplicativo.
Configurações de CORS que Correspondem a Produtos Reais
O CORS ganha um lugar em uma arquitetura quando muda o comportamento de um produto concreto, requisito de compatibilidade ou decisão de diagnóstico. Esses casos de uso descrevem primeiro o trabalho e a característica do protocolo em segundo lugar.
API de leitura pública
Um serviço pode permitir leituras não autenticadas de origens aprovadas ou todas as origens quando os dados são genuinamente públicos.
Aplicativo de página única
A API pode permitir a origem frontend de produção e origens de desenvolvimento selecionadas.
API de conta autenticada
Uma lista de permissão de origem explícita emparelha com suporte a credenciais e autorização do lado do servidor.
Metadados de resposta expostos
O servidor pode expor um campo limitado, como um ID de solicitação, sem expor todos os campos de resposta.
Frontend multi-tenant
A política pode resolver uma origem de inquilino registrada e rejeitar valores refletidos não confiáveis.
Serviço de upload separado
A pré-verificação pode aprovar o método requerido e o campo de conteúdo para uma origem de upload dedicada.
CORS, Política de Mesma Origem, CSRF e Autenticação
O CORS pertence a uma camada do HTTP e não deve ser confundido com camadas adjacentes. Uma implementação sólida identifica qual componente seleciona o valor, qual componente pode alterá-lo e quais evidências provam que a representação final está correta.
| Dimensão | CORS | Conceito relacionado ou alternativo |
|---|---|---|
| Política de mesma origem | Linha de base de segurança do navegador | Restringe o acesso a scripts entre origens |
| CORS | Permissão de leitura do servidor opt-in | Relaxa restrições selecionadas do navegador |
| Defesa contra CSRF | Protege ações que alteram o estado | Valida o contexto e a intenção da solicitação |
| Autenticação | Estabelece a identidade do chamador | Usa mecanismos de sessão ou credenciais |
| Autorização | Verifica operações permitidas | Aplica regras de negócio e de recursos |
Uma comparação é útil apenas se preservar os limites das camadas. Dois mecanismos podem coexistir em uma solicitação, e substituir um não substitui automaticamente o outro. Documente o comportamento selecionado em termos de entradas, saída observável, estado de falha e propriedade.
Erros de configuração de CORS e Correções Falsas
- Refletindo cada Origem. Ecoar entradas não validadas pode conceder acesso de leitura do navegador à origem de um atacante.
- Usando curinga com credenciais. Solicitações de navegador autenticadas exigem uma origem permitida explícita em vez de permissão curinga.
- Tratando o CORS como autenticação. O CORS governa o acesso de resposta do navegador; o servidor ainda deve autenticar e autorizar cada operação.
- Adicionando cabeçalhos apenas a respostas de sucesso. Erros e respostas de pré-vôo também precisam dos campos de política exigidos para que o navegador exponha diagnósticos úteis.
- Usando no-cors para resolver acesso. A resposta opaca resultante não é uma resposta de API normal legível e não concede permissão de servidor ausente.
- Esquecendo a variação do cache. Respostas dinâmicas de origem devem considerar a Origem no comportamento de cache para que a permissão de um inquilino não seja servida a outro.
A maioria das falhas se torna mais fácil de diagnosticar após remover suposições sobre o que uma biblioteca ou navegador fez automaticamente. Capture uma trilha mínima, redija segredos e mude uma variável controlada de cada vez. O objetivo é uma explicação estável da representação retornada, não uma coleção de ajustes de cabeçalho não relacionados.
Um Diagnóstico de CORS de Página para Origem
Esta sequência funciona como uma revisão de design antes do lançamento e como um diagnóstico de produção após mudanças de comportamento. Mantém as evidências do protocolo conectadas ao resultado da aplicação.
- Anote a origem da página e a origem de destino como esquema, host e porta.
- Inspecione o painel de rede do navegador para determinar se a troca com falha é pré-vôo ou solicitação real.
- Verifique o campo de solicitação de Origem e o valor exato de Access-Control-Allow-Origin na resposta.
- Para pré-vôo, compare o método solicitado e os nomes dos campos com as listas permitidas do servidor.
- Para credenciais, verifique a permissão explícita de origem, permissão de credenciais, regras de cookies e autorização de aplicação separadamente.
- Verifique redirecionamentos e respostas de gateway porque uma camada diferente pode omitir os campos necessários.
- Valide com o contexto real do navegador; um sucesso na linha de comando não prova que a política do navegador é aprovada.
Termine a revisão salvando uma pequena amostra aceita e uma amostra rejeitada com as mesmas regras de redação. Mudanças futuras podem então ser comparadas contra a identidade da página conhecida, campos esperados e conteúdo decodificado em vez de memória ou capturas de tela apenas.
Segurança e Observabilidade para CORS
CORS participa de um caminho de solicitação que pode cruzar navegadores, gateways, caches e servidores de origem. Cada salto deve aceitar apenas os valores que entende, preservar os campos que devem sobreviver e evitar copiar credenciais ou dados pessoais em logs. A sintaxe do protocolo não é autorização.
Registros operacionais devem capturar a URL solicitada, URL final, status, tipo de representação, nomes de campos relevantes e um marcador de conteúdo delimitado. Corpos completos e valores de credenciais raramente são necessários para diagnósticos de rotina e podem criar riscos de retenção desnecessários.
O comportamento do navegador e o comportamento HTTP direto são superfícies de teste diferentes. CORS, armazenamento de cookies, descompressão automática e tratamento de redirecionamentos podem ser realizados pelo navegador ou pela biblioteca antes que o código da aplicação veja um resultado. Registre o cliente e seus padrões ao comparar capturas.
Padrões que Definem CORS
o protocolo CORS do Fetch Standard define o processamento CORS do navegador atual. Esta fonte primária fixa o vocabulário e as fronteiras usadas neste artigo, enquanto o comportamento da implementação ainda precisa ser observado no cliente e na implantação selecionados.
o guia CORS da MDN explica trocas simples e pré-vôo. Esta fonte primária fixa o vocabulário e as fronteiras usadas neste artigo, enquanto o comportamento da implementação ainda precisa ser observado no cliente e na implantação selecionados.
a especificação de origem da web define o conceito de origem usado pela segurança da web. Esta fonte primária fixa o vocabulário e as fronteiras usadas neste artigo, enquanto o comportamento da implementação ainda precisa ser observado no cliente e na implantação selecionados.
o guia de política de mesma origem da MDN descreve a fronteira do navegador que o CORS pode relaxar. Esta fonte primária fixa o vocabulário e as fronteiras usadas neste artigo, enquanto o comportamento da implementação ainda precisa ser observado no cliente e na implantação selecionados.
O Modelo Mental Correto de CORS
CORS é uma permissão de leitura de resposta imposta pelo navegador, controlada por campos do servidor; complementa autenticação, autorização, política de cookies e defesas contra falsificação de solicitação, em vez de substituí-las.
Coloque essa regra em um teste de aceitação. Declare qual participante envia o sinal, qual participante o interpreta, quais intermediários podem alterar o caminho e qual marcador de conteúdo prova sucesso. Isso torna o CORS parte de um sistema observável, em vez de um rótulo anexado após uma falha.
Pronto para Validar uma Resposta Web Pública?
Use a API de Scraping Universal Scrapeless para recuperar conteúdo público aprovado e verificar o contrato de representação descrito neste guia.
Inscreva-se hoje e ganhe $5 em crédito gratuito — sem cartão de crédito necessário.
Reivindique seu crédito de $5 →FAQ
O CORS bloqueia a solicitação de alcançar o servidor?
Nem sempre. O navegador pode enviar uma solicitação real e depois bloquear o script da página de ler a resposta. Um pré-vôo com falha impede que a solicitação real associada seja enviada.
O CORS pode proteger uma API de clientes da linha de comando?
Não. O CORS é imposto pelos navegadores da web. Clientes HTTP diretos podem enviar solicitações, portanto a API deve impor autenticação, autorização, validação e política de taxa por conta própria.
O Access-Control-Allow-Origin pode ser definido para várias origens?
O campo de resposta carrega um valor de origem permitido ou um curinga elegível, não uma lista de permissão separada por vírgulas. Servidores que suportam várias origens avaliam a Origem da solicitação e retornam o valor aprovado correspondente.
Por que uma solicitação funciona no curl, mas falha em um navegador?
Um cliente da linha de comando não aplica a política de mesma origem do navegador. O navegador verifica os campos CORS e pode enviar um pré-vôo antes de expor a resposta ao script.
Ativar CORS previne CSRF?
Não. O CORS controla se o script do navegador pode ler uma resposta, enquanto o CSRF diz respeito a solicitações indesejadas que alteram o estado feitas com a autoridade de um usuário. Utilize defesas dedicadas contra falsificação de solicitações e autorização do servidor.