Skip to content

Glossary

CORS

Cross-Origin Resource Sharing

By Published Updated

CORS (Cross-Origin Resource Sharing) é o mecanismo do navegador que controla quando o JavaScript de uma origem pode ler respostas de outra. Por padrão, navegadores bloqueiam respostas XHR/fetch cross-origin — cabeçalhos CORS do servidor desbloqueiam o acesso controlado.

Os dois principais cabeçalhos de resposta:

  • Access-Control-Allow-Origin: quais origens podem ler a resposta. Uma origem específica ou * (qualquer).
  • Access-Control-Allow-Credentials: se cookies podem fluir com requisições cross-origin. true requer que a origem seja específica, não *.

Para requisições que não são “simples” (cabeçalhos personalizados, métodos diferentes de GET/POST, corpos JSON), o navegador envia primeiro uma requisição OPTIONS de preflight para verificar o que é permitido. O servidor responde com Access-Control-Allow-Methods e Access-Control-Allow-Headers; a requisição real só é disparada se o preflight for bem-sucedido.

Equívocos comuns: o CORS não é um mecanismo de segurança do lado do servidor — é uma restrição imposta pelo navegador que protege os usuários de um site ler dados em seu nome de outro site. Os servidores ainda podem receber e processar requisições cross-origin; o CORS apenas controla se o navegador entrega a resposta ao JS chamador.

O que “origem” significa precisamente: a tupla (esquema, host, porta). http://example.com e https://example.com são origens diferentes (esquema diferente). https://api.example.com e https://example.com são origens diferentes (subdomínio diferente). https://example.com:8080 e https://example.com são origens diferentes (porta diferente). Esta é a política de mesma origem sobre a qual o CORS adiciona exceções. O Internet Explorer ignorava a parte da porta — uma peculiaridade que produziu anos de bugs entre navegadores até que a aposentadoria do IE eliminou a questão.

Problemas comuns em produção: o curinga Access-Control-Allow-Origin: * bloqueia credenciais por especificação; se você precisar de cookies em uma requisição cross-origin, deve refletir a Origin da requisição de volta especificamente. Adicionar um cabeçalho Authorization eleva a requisição de “simples” para “com preflight”, dobrando as viagens de ida e volta — armazenar em cache o preflight via Access-Control-Max-Age (até 7200 segundos no Chrome, 600 no Firefox) é a mitigação padrão. Por fim, o erro CORS do navegador no console do DevTools é genuinamente uma decisão do navegador — os logs do servidor mostrarão que a requisição chegou ao backend e foi processada normalmente; a resposta foi simplesmente descartada no lado do cliente. Referência: WHATWG Fetch — HTTP-CORS Protocol.

Exemplo prático: um POST JSON com preflight

Um SPA em https://app.example.com faz um POST JSON com um token bearer para https://api.example.com/v1/orders. Como a requisição usa Content-Type: application/json e um cabeçalho Authorization, ela não é simples. O navegador primeiro envia OPTIONS /v1/orders com Origin: https://app.example.com, Access-Control-Request-Method: POST e Access-Control-Request-Headers: authorization,content-type. O servidor responde com 204 com Access-Control-Allow-Origin: https://app.example.com, Access-Control-Allow-Methods: POST, Access-Control-Allow-Headers: authorization,content-type e Access-Control-Max-Age: 600. Só então o POST real é disparado. Definir Max-Age: 600 evita o preflight pelos próximos 10 minutos, eliminando uma viagem de ida e volta de cada chamada subsequente — mensurável como uma redução de 50-100ms em links transatlânticos.

Quando o CORS não é suficiente

O CORS protege os usuários de leituras cross-origin; ele não protege servidores de requisições indesejadas. Endpoints que alteram estado ainda precisam de tokens CSRF ou cookies SameSite, e a autenticação ainda precisa de validação adequada de tokens no lado do servidor. Uma API pública protegida por Access-Control-Allow-Origin: * é acessível por qualquer pessoa — o CORS apenas permitiu que o navegador evidenciasse esse fato. Para um contexto arquitetural mais profundo, consulte a referência CORS do MDN, que espelha a especificação WHATWG com exemplos práticos.

Frequently asked questions

O que é CORS?
CORS (Cross-Origin Resource Sharing) é um mecanismo de segurança do navegador que controla quais requisições HTTP cross-origin o JavaScript pode fazer. O navegador bloqueia requisições de uma origem (ex.: app.example.com) para outra (api.other.com) a menos que o servidor responda com o cabeçalho Access-Control-Allow-Origin adequado.
Como o CORS funciona na prática?
Um app React em https://app.example.com faz uma requisição para https://api.example.com/data. O navegador adiciona um cabeçalho Origin; a API deve responder com Access-Control-Allow-Origin: https://app.example.com (ou *). Sem esse cabeçalho, o navegador bloqueia a resposta mesmo que o servidor a tenha enviado.
Qual é a diferença entre uma requisição simples e um preflight CORS?
Requisições simples (GET/POST com cabeçalhos padrão e tipos de conteúdo) são enviadas diretamente com o cabeçalho Origin. Requisições de preflight são enviadas automaticamente pelo navegador antes de requisições complexas (DELETE, cabeçalhos personalizados, corpo JSON) como uma chamada OPTIONS para perguntar ao servidor se a requisição real é permitida.
O CORS protege o servidor de ser acessado diretamente?
Não — o CORS se aplica apenas ao JavaScript baseado em navegador. curl, Postman e chamadas servidor-a-servidor ignoram o CORS completamente. O CORS protege o navegador do usuário de ser enganado para enviar requisições autenticadas cross-origin; ele não protege o endpoint da API de acesso direto.

Related

Published May 15, 2026 · Last reviewed May 31, 2026