CORS mal compreendido: risco real de segurança em aplicações web

O CORS não é um firewall, nem uma camada de autenticação, é um contrato entre navegador e servidor sobre quais origens podem ler respostas. Quando mal configurado, ele não bloqueia requisições (o navegador as faz normalmente), mas permite que sites maliciosos leiam respostas sensíveis de APIs autenticadas. O caso do Zoom em 2019 foi o primeiro grande alerta prático: usar um 'hack de imagem' para burlar o CORS revelou que a equipe ignorava que localhost não é isento de políticas CORS, Chrome, Firefox e Safari aplicam restrições completas ali desde 2017. A falha não foi técnica, mas conceitual: confundir 'não bloquear requisição' com 'permitir leitura da resposta'.

Isso se repete hoje com CVEs recentes como o CVE-2026-32610 no Glances, onde o middleware Starlette refletia qualquer cabeçalho Origin mesmo com allow_credentials=True, ou o CVE-2024-25124 no Fiber, que aceitava configurações contraditórias (* + credenciais) até a versão 2.52.1. Em todos os casos, o problema não está na implementação do navegador, mas na falsa segurança gerada por ferramentas de desenvolvimento (como Postman ou curl) que ignoram CORS, levando devs a acreditar que 'funciona localmente' significa 'está seguro em produção'.

A cobertura CEVIU anterior tratou de falhas de XSS, SSRF e má configuração de APIs, mas nenhuma delas abordou o erro de modelo mental central aqui: a confusão entre controle de requisição (que o CORS não faz) e controle de leitura de resposta (que ele sim regula). A novidade desta notícia é que ela conecta explicitamente essa falha conceitual a riscos reais em 2026, como o CVE-2026-32610 no Glances, e mostra que o padrão de 'copiar e colar middleware CORS com * + credentials' ainda é comum em stacks Python (FastAPI, Starlette) e Go (Fiber), mesmo após anos de alertas. Não houve mudança de especificação, mas sim a consolidação de um padrão perigoso como prática corrente.

Desenvolvedores que não entendem CORS estão, sem saber, escrevendo código que funciona em desenvolvimento e quebrando em produção, ou pior: funcionando de forma insegura em produção. Isso afeta diretamente a experiência do desenvolvedor (DX): frameworks modernos como FastAPI e Next.js incluem middlewares CORS 'prontos', mas sua má configuração vira uma vulnerabilidade crítica em minutos. Mais grave: quando combinado com credenciais (cookies, headers de autorização), um CORS mal configurado transforma qualquer XSS em um ataque de exfiltração de dados privilegiados, como visto no Spring Authorization Server (CVE-2026-22752) e no Dify (CVE-2025-63388). Isso não é 'configuração avançada': é a primeira linha de defesa contra roubo de sessão em aplicações web.