O que é CORS (Cross-Origin Resource Sharing)?

CORS é um mecanismo do navegador que permite ao servidor declarar quais outras origens podem chamá-lo, relaxando de propósito a política de same-origin. Dois reenquadramentos dissolvem a maior parte da confusão: quem aplica é o navegador (não o servidor — por isso o curl funciona), e quem corrige é o servidor (não o seu frontend — por isso nenhuma quantidade de JavaScript ajuda). Todo o resto são headers.

Principais pontos

O protocolo inteiro, na rede

# Preflight: o navegador pergunta antes de um PUT com header de autenticação
OPTIONS /classes/Product HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: x-parse-session-token

# A licença por escrito do servidor
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com   ← esta origin pode ler
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: x-parse-session-token
Access-Control-Max-Age: 86400        ← cacheie esta resposta; pule o preflight de amanhã

# Então, e só então, a requisição real é enviada.

Como isso aparece no código da aplicação — e a verdade de plataforma que as abas ensinam: CORS é um assunto do navegador, que apps nativos nunca encontram:

// Browser JavaScript — Back4app JS SDK
// A cross-origin call that just works: the platform answers the
// preflight and sends the CORS headers, so the browser lets it through
Parse.initialize('APP_ID', 'JS_KEY');
Parse.serverURL = 'https://parseapi.back4app.com'; // different origin than your site

const products = await new Parse.Query('Product').find();
// No proxy hacks, no "disable CORS" — the server side is configured correctly.

// Flutter / Dart — Back4app Flutter SDK
// Native apps have no same-origin policy — CORS is a browser concern.
// Flutter Web, however, DOES enforce it: same browser rules apply there.
final query = QueryBuilder<ParseObject>(ParseObject('Product'));
final response = await query.query();
// Works identically on mobile and web because the server sends CORS headers.

// iOS / Swift — Back4app Swift SDK
// No browser, no same-origin policy: CORS never applies to native iOS.
// The same backend serves browsers (with CORS headers) and apps alike.
let query = Product.query()
query.find { result in
  if case .success(let products) = result { render(products) }
}

// Android / Kotlin — Back4app Android SDK
// No browser, no same-origin policy: CORS never applies to native Android.
// The same backend serves browsers (with CORS headers) and apps alike.
val query = ParseQuery.getQuery<ParseObject>("Product")
query.findInBackground { products, e ->
  if (e == null) render(products)
}

O fluxo, decidido

Dois detalhes carregam a maioria das sessões de debug: uma requisição simples (GET/HEAD/POST com headers da safelist e content types comuns) pula o preflight — e é por isso que adicionar um header Authorization de repente “quebra” um endpoint que funcionava; e requisições com credenciais apertam tudo — cookies só fluem com Access-Control-Allow-Credentials: true mais uma origin exata, nunca o wildcard, conforme a especificação.

Como corrigir erros de CORS (erro → causa → correção)

E o anti-fix que merece nome: desabilitar por flag de navegador e proxies permissivos de dev tornam o erro invisível só na sua máquina — o deploy continua quebrado para os usuários. A correção real é uma configuração de servidor medida em minutos.

Casos de uso comuns

• SPA + API em origens diferentes — app.example.com chamando api.example.com: o caso cotidiano para o qual o CORS existe.
• Desenvolvimento local — localhost:3000 contra um backend real; permita a origin de dev, não desligue o escudo.
• APIs públicas — origin wildcard, sem credenciais: correto e seguro para dados genuinamente públicos.
• Plataformas multi-frontend — vários apps, um backend, uma lista explícita de origens por ambiente.
• Backends BaaS — a plataforma responde os preflights e envia os headers; seu trabalho se reduz a declarar as origens permitidas.

Wildcard vs. origens explícitas: matriz de decisão

Um reenquadramento de segurança fecha a matriz: CORS não é controle de acesso — apps nativos e servidores o ignoram por completo, então ele protege usuários de navegador contra sites maliciosos, não a sua API contra chamadores. Autenticação e permissões na camada de dados fazem esse trabalho; o CORS só decide quais scripts de quais sites podem ler as respostas.

Limitações e trade-offs

• Só governa navegadores. Qualquer coisa que não seja navegador passa direto — nunca confunda uma lista de origens com autorização.
• Preflights custam um round trip em requisições não simples; o cache via Access-Control-Max-Age é a correção barata e esquecida.
• Má configuração falha fechada e barulhenta — bom para a segurança, brutal para o debug sem a tabela erro→correção acima.
• Listas de origens são estado de ambiente. Origens de staging vazam para configs de produção; audite a lista como qualquer credencial.
• CORS ≠ CSRF ≠ CSP. Siglas vizinhas, defesas separadas — cookies ainda precisam de proteção SameSite/token, páginas ainda precisam de uma content policy, e o CORS cuida apenas da leitura cross-origin.

CORS no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. A tarefa do CORS já vem resolvida: as APIs da plataforma respondem preflights e enviam os headers corretos, então apps de navegador chamam o backend a partir das origens permitidas sem gambiarras de proxy — a aba JavaScript acima é a experiência inteira — enquanto as abas Flutter, Swift e Kotlin demonstram a verdade mais silenciosa: clientes nativos nunca encontram a cerimônia. A segurança real fica onde pertence: sessões, ACLs e permissões em nível de classe aplicadas server-side em toda requisição, venha de qual origem vier.