Como corrigir erro CORS de cabeçalho ausente de Access-Control-Allow-Origin

O erroNenhum cabeçalho ‘Access-Control-Allow-Origin’ está presente no recurso solicitado é o erro CORS mais comum. Isso significa que o navegador bloqueou sua solicitação de origem cruzada porque o servidor não disse que ela era permitida. Veja como consertar isso corretamente.

Por que isso acontece

Os navegadores aplicam a Política de Mesma Origem para segurança — uma página emapp.example.com não pode fazer solicitações livremente paraapi.other.com. Para solicitações de origem cruzada, o servidor deve incluir umAccess-Control-Allow-Origin cabeçalho informando quais origens são permitidas. Se estiver faltando, o navegador bloqueia a resposta e mostra este erro.

Ponto-chave: Isso é imposto pelo navegador e corrigido no SERVIDOR. O cliente não pode adicionar este cabeçalho — o servidor deve enviá-lo.

Correção 1: Expresse com o pacote cors

npm install cors

const cors = require('cors');

// Allow all origins (development only)
app.use(cors());

// ✅ Production: allow specific origin
app.use(cors({
  origin: 'https://app.example.com',
}));

// ✅ Multiple allowed origins
const allowed = ['https://app.example.com', 'https://admin.example.com'];
app.use(cors({
  origin: (origin, callback) => {
    if (!origin || allowed.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
}));

Correção 2: cabeçalhos manuais expressos

app.use((req, res, next) => {
  res.header('Access-Control-Allow-Origin', 'https://app.example.com');
  res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
  res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');

  // Handle preflight OPTIONS requests
  if (req.method === 'OPTIONS') {
    return res.sendStatus(204);
  }
  next();
});

Correção 3: Nginx

location /api/ {
    add_header 'Access-Control-Allow-Origin' 'https://app.example.com' always;
    add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
    add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always;

    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' 'https://app.example.com';
        add_header 'Access-Control-Max-Age' 86400;
        return 204;
    }

    proxy_pass http://localhost:3000;
}

Correção 4: com credenciais (cookies/autenticação)

// When sending cookies or auth headers cross-origin:

// Server: exact origin (NOT wildcard) + allow credentials
app.use(cors({
  origin: 'https://app.example.com',   // must be exact, not '*'
  credentials: true,
}));

// Client: include credentials
fetch('https://api.example.com/data', {
  credentials: 'include',
});

// ❌ This combination FAILS:
// origin: '*' with credentials: true
// The browser rejects wildcard origin when credentials are included

A alternativa de proxy de desenvolvimento

// Avoid CORS during development entirely with a dev proxy

// vite.config.ts
export default {
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:3000',
        changeOrigin: true,
      }
    }
  }
};
// Frontend calls /api/... which the dev server proxies to your backend -
// same origin, no CORS. (Production still needs proper CORS headers.)

Erros Comuns

// 🐛 Setting CORS headers in BOTH nginx and Express
// Results in duplicate Access-Control-Allow-Origin headers,
// which the browser rejects. Set them in ONE place.

// 🐛 Wildcard with credentials
res.header('Access-Control-Allow-Origin', '*');   // fails with credentials

// 🐛 Forgetting to handle OPTIONS preflight
// PUT/DELETE/JSON requests send a preflight OPTIONS first -
// it must get a valid CORS response too

// 🐛 Trying to fix it in the frontend
// You CANNOT add Access-Control-Allow-Origin from client code -
// it must come from the server

Depuração

# Check what headers the server actually returns
curl -I -H "Origin: https://app.example.com" https://api.example.com/data

# Look for:
# Access-Control-Allow-Origin: https://app.example.com  ← should be present

# If it's missing, the server isn't configured correctly.
# If it's the wrong origin, fix the server's allowed origins.

Perguntas Frequentes

P: Por que não consigo corrigir isso no meu código de front-end?
R: O CORS é aplicado pelo navegador e controlado pelo SERVIDOR. OAccess-Control-Allow-Origin o cabeçalho deve vir do servidor que responde à solicitação. Nenhuma quantidade de código frontend pode adicioná-lo – você deve configurar o servidor (ou usar um proxy).

P: Por que funciona no Postman, mas não no navegador?
R: O CORS só é aplicado por navegadores. Postman e curl fazem solicitações diretamente sem a verificação CORS do navegador. Isso confirma que seu servidor funciona – você só precisa adicionar os cabeçalhos CORS para clientes do navegador.

P: Devo usar apenas Access-Control-Allow-Origin: *?
R: Somente para APIs verdadeiramente públicas sem credenciais. Para qualquer coisa com autenticação ou cookies, você deve especificar as origens exatas (o curinga falha nas credenciais). Especificar origens exatas também é mais seguro — não use* em produção para APIs autenticadas.

P: Onde devo definir os cabeçalhos CORS – nginx ou o aplicativo?
R: Apenas um lugar. Se você configurá-los no nginx e no seu aplicativo, obterá cabeçalhos duplicados, que os navegadores rejeitam. Escolha uma camada (geralmente o aplicativo para flexibilidade ou nginx se você tiver um proxy reverso) e configure o CORS lá.

P: Por que meu POST funciona, mas o PUT falha?
R: PUT/DELETE e solicitações com corpos JSON ou cabeçalhos personalizados acionam uma solicitação OPTIONS de comprovação. Seu servidor também deve responder a OPTIONS com cabeçalhos CORS válidos. Certifique-se de que sua configuração CORS lide com o método OPTIONS, não apenas GET/POST.

Conclusão

“Nenhum cabeçalho ‘Access-Control-Allow-Origin’ está presente” significa que o servidor não informou ao navegador que sua solicitação de origem cruzada é permitida. A correção está sempre no SERVIDOR:adicione oAccess-Control-Allow-Origin cabeçalho por meio do pacote cors (Express), cabeçalhos manuais ou configuração nginx, especificando origens exatas (obrigatório ao usar credenciais). Lide com solicitações de comprovação de OPTIONS, defina o CORS em apenas uma camada para evitar duplicatas e lembre-se de que você não pode corrigi-lo a partir do código de front-end. Para desenvolvimento, um proxy de servidor de desenvolvimento evita totalmente o CORS – mas a produção sempre precisa de cabeçalhos CORS adequados no lado do servidor.