CORS liberado com cookie: quando "liberar geral" vira falha de segurança

Refletir a origem de qualquer site junto com Access-Control-Allow-Credentials deixa qualquer página agir em nome de quem está logado no seu. Como configurar do jeito certo.

O erro de CORS é o mais irritante do desenvolvimento web, e a correção mais sugerida é liberar tudo. Sozinho, Access-Control-Allow-Origin: * costuma ser inofensivo: o navegador não manda cookie para *. O problema é a combinação abaixo.

// ❌ aceita QUALQUER site, e com cookie
res.setHeader("Access-Control-Allow-Origin", req.headers.origin);
res.setHeader("Access-Control-Allow-Credentials", "true");

Com isso, um site qualquer que o seu usuário visite pode chamar a sua API usando o cookie de sessão dele — e ler a resposta. Dados da conta, pedidos, mensagens: tudo que a pessoa vê logada, o outro site também vê.

Como configurar

// ✅ só as suas origens recebem permissão
const PERMITIDAS = new Set(["https://seusite.com.br", "https://www.seusite.com.br"]);

app.use((req, res, next) => {
  const origem = req.headers.origin;
  if (origem && PERMITIDAS.has(origem)) {
    res.setHeader("Access-Control-Allow-Origin", origem);
    res.setHeader("Access-Control-Allow-Credentials", "true");
    res.setHeader("Vary", "Origin");
  }
  next();
});

• Compare a origem inteira e exata. origem.includes("seusite") aceita seusite.com.br.atacante.com.
• Não use regex sem âncoras (^ e $) para validar a origem.
• Se a API usa o cabeçalho Authorization e não cookie, você nem precisa de Allow-Credentials.

Dicas curtas de segurança para quem cria com IA: siga @npx_vibedefender no Instagram.