Desenvolvedores não entendem CORS (2019)

Artigo original ↗ Discussão no Hacker News ↗

Sentimento geral

  • Muitos participantes admitem que realmente não entendem CORS, mesmo desenvolvedores web experientes.
  • O próprio fio de comentários é citado como evidência de que o ecossistema está profundamente confuso sobre CORS e seu modelo de ameaça.

Política de Mesma Origem vs CORS

  • Vários comentários enfatizam que o mecanismo de segurança central é a Política de Mesma Origem (SOP); CORS é uma forma de relaxá-la seletivamente.
  • Esclarecimento importante: o navegador normalmente bloqueia a leitura de respostas de origem cruzada, não o envio de requisições; CORS permite algumas leituras de origem cruzada quando o servidor opta por isso.

Modelo de ameaça e o que o CORS realmente protege

  • CORS é descrito como protegendo o usuário em um navegador de sites maliciosos de terceiros, não protegendo o backend de clientes HTTP genéricos.
  • Cenário típico: o usuário está logado no site A (cookies definidos) e então visita o site malicioso B, que tenta ler dados privados ou agir em nome dele contra A.
  • Vários comentários observam sobreposição e confusão com proteções CSRF; alguns confundem os dois, outros insistem que o CSRF ainda deve ser tratado separadamente.

Preflight, requisições “simples” e casos de borda

  • Muitas armadilhas de CORS decorrem da distinção entre:
    • Requisições “simples” (GET, alguns POSTs com tipos de conteúdo específicos) que ignoram o preflight.
    • Requisições “não simples” (por exemplo, POST JSON, cabeçalhos personalizados) que exigem um preflight OPTIONS e aprovação explícita de CORS.
  • Exemplos mostram como uma verificação frouxa de Content-Type (por exemplo, aceitar JSON em text/plain ou codificações de formulário) pode contornar suposições baseadas em preflight.
  • Os comentaristas enfatizam que comportamento potencialmente destrutivo não deve ser exposto por métodos “seguros” ou simples como GET.

Uso indevido e equívocos

  • Padrão comum: desenvolvedores “só colocam Access-Control-Allow-Origin: *” para fazer funcionar, ignorando implicações de segurança.
  • Alguns acreditam erroneamente que CORS pode impedir que outros sites ou scrapers chamem uma API de forma alguma; outros corrigem isso, apontando que clientes sem navegador ou com CORS desativado não são afetados.
  • O exemplo do Zoom em localhost é considerado enganoso: os cabeçalhos CORS não teriam “restringido” totalmente o acesso como foi sugerido.

Experiência do desenvolvedor e aprendizado

  • Depurar é descrito como doloroso: mensagens de erro do navegador são opacas, as visualizações das devtools são confusas e a causa real (cabeçalhos do servidor) fica escondida.
  • Muitos veem CORS como algo de “configurar e esquecer”; eles reaprendem a cada vez e depois esquecem.
  • Alguns recomendam a documentação de CORS da MDN e entender primeiro a SOP; outros argumentam que a especificação e a documentação são complexas demais e, portanto, o protocolo é efetivamente “ruim”.

Arquitetura e alternativas

  • Uma visão: o melhor é hospedar frontend e backend na mesma origem (via reverse proxy) e evitar CORS completamente.
  • Contraponto: arquiteturas do mundo real frequentemente exigem origens separadas, então entender e configurar CORS continua necessário.