CORS: por que Existe e Como Funciona de Verdade

O problema

Tem poucos assuntos web que geram tanta irritacao por tao pouco entendimento real quanto CORS.

O fluxo clássico e este:

• frontend chama API
• browser reclama
• alguém diz “libera tudo ai”

Isso resolve algumas vezes.

Também cria configuração ruim com frequência impressionante.

O problema central e que muita gente tenta decorar header sem entender a pergunta original:

por que o browser esta se metendo nessa request?

Modelo mental

CORS significa Cross-Origin Resource Sharing.

Ele existe porque o browser aplica regras para requests entre origens diferentes.

Origem, aqui, e a combinação de:

• protocolo
• host
• porta

Se uma pagina em https://app.exemplo.com tenta ler resposta de https://api.exemplo.com, já estamos falando de origem diferente.

E o browser quer saber:

essa outra origem autorizou compartilhar a resposta com esta pagina?

Quebrando o problema

CORS e politica do browser

Esse e o ponto que mais limpa a cabeca.

CORS e imposto pelo browser.

Isso significa:

• Postman não liga para CORS
• backend chamando backend não liga para CORS
• curl não liga para CORS

Quem bloqueia leitura da resposta no fluxo tipico e o navegador.

Por isso o mesmo endpoint pode:

• funcionar no servidor
• funcionar no Postman
• falhar no frontend no browser

O que o servidor manda

Quando quer autorizar, o servidor responde com headers como:

• Access-Control-Allow-Origin
• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Credentials

Esses headers não “abrem a internet”.

Eles dizem ao browser o que aquela origem pode compartilhar.

O que e preflight

Em alguns casos o browser não faz a request final direto.

Ele primeiro manda uma OPTIONS para perguntar se aquilo e permitido.

Isso e o preflight.

Ele aparece com mais frequência quando:

• o metodo não e simples
• ha headers customizados
• ha uso de credenciais em certos cenarios
• o request foge do conjunto mais básico

Se a resposta do preflight não autoriza direito, o browser nem segue com o fluxo da forma esperada.

Credenciais deixam o caso mais sensivel

Quando entram cookie, autenticação baseada em sessao ou outras credenciais, o cuidado aumenta.

Não basta pensar em origem.

Você precisa alinhar:

• origem permitida
• envio de credenciais
• configuração de cookie
• comportamento do frontend

E tem uma armadilha famosa:

Access-Control-Allow-Origin: * não combina com credenciais.

Se a aplicação precisa enviar cookie entre origens, a politica precisa ser mais especifica.

CORS não substitui autenticação

Outra confusao comum:

achar que CORS protege a API por si só.

Não protege.

Se a API esta publica e aceita request com token valido, CORS não e a sua camada principal de autorização.

Ele controla como o browser compartilha respostas entre origens.

Não e substituto de:

• auth
• authz
• validação
• rate limiting

Exemplo simples

Imagine:

• frontend em https://app.exemplo.com
• API em https://api.exemplo.com

O frontend faz:

fetch('https://api.exemplo.com/profile', {
  credentials: 'include',
})

O browser pode mandar cookie, mas só vai deixar o frontend ler a resposta se o servidor responder algo coerente como:

• Access-Control-Allow-Origin: https://app.exemplo.com
• Access-Control-Allow-Credentials: true

Se o backend responder com configuração errada, o request pode até chegar na API.

Mas o browser ainda bloqueia o acesso do JavaScript ao resultado.

Do ponto de vista da API, a requisição pode ter sido atendida.

Do ponto de vista do browser, aquela resposta não pode ser exposta para esse JavaScript.

Esse detalhe confunde muita gente.

Porque parece que “a API falhou”, quando na verdade a politica do browser que barrou a leitura.

Erros comuns

• Tratar CORS como segurança completa da API.
• Achar que qualquer cliente HTTP sofre CORS.
• Responder * por reflexo sem pensar em credenciais.
• Ignorar preflight e depois estranhar request OPTIONS.
• Debugar só no backend e esquecer que o bloqueio esta no navegador.

Como um senior pensa

Quem tem mais experiência normalmente separa tres perguntas logo no início:

1. Quem esta fazendo a chamada, browser ou servidor?
2. As origens sao diferentes?
3. Ha credenciais, headers customizados ou preflight no meio?

Só essa triagem já elimina metade do caos.

O raciocínio costuma ser:

“Antes de mexer em header no escuro, eu quero saber quem esta aplicando a restrição e qual origem precisa ser autorizada.”

O que o entrevistador quer ver

Em entrevista, CORS costuma ser um teste rápido de maturidade em web.

O avaliador quer ver se você entende o mecanismo e não só os nomes dos headers.

Sinais bons:

• você diz que CORS e politica do browser
• explica origem com protocolo, host e porta
• menciona preflight
• separa CORS de autenticação e autorização

Uma resposta forte costuma soar assim:

“CORS existe porque o browser restringe leitura entre origens diferentes. O servidor responde com headers dizendo o que pode compartilhar. Se houver credenciais ou headers fora do básico, pode rolar preflight antes.”

Decorar header ajuda pouco. Entender quem esta bloqueando o que muda o debug inteiro.