Como corrigir o erro CORS do cabeçalho ‘No Access-Control-Allow-Origin’ em 2026

Você faz uma solicitação do seu frontend para uma API e o navegador a bloqueia com:Access to fetch at '...' from origin '...' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Este é um dos erros mais comuns e incompreendidos no desenvolvimento web. Aqui está o que realmente causa isso e como corrigi-lo corretamente.

O que o CORS realmente é

CORS (Cross-Origin Resource Sharing) é um mecanismo de segurança do navegador. Quando seu JavaScript está ativadohttps://app.example.com faz uma solicitação parahttps://api.other.com, o navegador a considera uma solicitação de origem cruzada e exige que o servidor a permita explicitamente por meio de cabeçalhos de resposta. Se o servidor não enviar umAccess-Control-Allow-Origin cabeçalho que inclui sua origem, o navegador bloqueia a resposta – mesmo que o servidor tenha processado a solicitação com sucesso.

Visão principal:O CORS é aplicado pelo navegador e a correção reside no servidor, não no seu código de front-end. Você não pode corrigir um erro de CORS alterando apenas sua chamada de busca.

Correção 1: Configure o servidor para enviar o cabeçalho

A correção correta é fazer a API responder com os cabeçalhos CORS corretos. No Expresso, use ocors intermediário:

const cors = require('cors');

app.use(cors({
  origin: 'https://app.example.com',
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  credentials: true
}));

Definirorigin para a origem exata do seu frontend. Não use um curinga* na produção se você enviar credenciais (cookies ou cabeçalhos de autenticação) — os navegadores rejeitam a combinação deAccess-Control-Allow-Origin: * comcredentials: true.

Correção 2: lidar com solicitações de comprovação (OPÇÕES)

Para qualquer solicitação que não seja um simples GET/POST — por exemplo, uma que enviaContent-Type: application/json ou umAuthorization header — o navegador primeiro envia uma simulaçãoOPTIONS solicitar pedindo permissão. Seu servidor deve responder com os cabeçalhos apropriados. Ocors O middleware acima trata disso automaticamente, mas se você definir os cabeçalhos manualmente, deverá manipular OPTIONS explicitamente:

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');
  if (req.method === 'OPTIONS') {
    return res.sendStatus(204); // Respond to preflight, do not fall through
  }
  next();
});

Um erro comum é não responder ao comprovante OPTIONS – o navegador o envia, não obtém nenhuma resposta CORS válida e bloqueia a solicitação real antes que ela seja feita.

Correção 3: combine exatamente a origem

A origem deve corresponder precisamente – contagem de protocolo, domínio e porta. Todas essas são origens diferentes do navegador:

Se sua origem permitida forhttps://example.com mas seu aplicativo carrega dehttps://www.example.com, o CORS o bloqueia. Permita todas as origens que o aplicativo realmente usa ou normalize para uma.

Correção 4: use uma origem dinâmica para vários front-ends

Se várias origens precisarem de acesso (preparação, produção, localhost), valide em uma lista de permissões em vez de codificá-la:

const allowed = [
  'https://app.example.com',
  'https://staging.example.com',
  'http://localhost:3000'
];

app.use(cors({
  origin: (origin, callback) => {
    if (!origin || allowed.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  credentials: true
}));

Correção 5: para desenvolvimento local, use um proxy

Durante o desenvolvimento, você pode evitar o CORS fazendo proxy de solicitações de API por meio de seu servidor de desenvolvimento para que pareçam ter a mesma origem. Na página:

// vite.config.js
export default {
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:5000',
        changeOrigin: true
      }
    }
  }
};

Agora seu frontend chama/api/... em sua própria origem e o servidor de desenvolvimento o encaminha. Esta é uma conveniência de desenvolvimento, não uma correção de produção – a produção ainda precisa de cabeçalhos CORS adequados na API.

O que NÃO fazer

Não use extensões de navegador que desativem o CORS e não dê um tapaAccess-Control-Allow-Origin: * em tudo para fazer o erro desaparecer. O curinga expõe sua API a todos os sites da Internet e quebra as solicitações credenciadas. CORS é um recurso de segurança – configure-o corretamente em vez de desativá-lo.

Perguntas Frequentes

P: Por que a solicitação funciona no Postman, mas não no navegador?
R: O Postman não aplica o CORS – apenas os navegadores o fazem. A solicitação que chega ao servidor prova que o servidor funciona; o navegador bloqueia a resposta porque faltam os cabeçalhos CORS. Corrija os cabeçalhos no servidor.

P: Posso corrigir o CORS no front-end?
R: Não. Os cabeçalhos CORS devem vir do servidor que responde à solicitação. A única solução alternativa no frontend é um proxy de desenvolvimento, que faz com que as solicitações tenham a mesma origem durante o desenvolvimento.

P: Por que minha solicitação OPTIONS de simulação falha?
R: O servidor não está respondendo a OPTIONS com os cabeçalhos CORS corretos e um status 2xx. Certifique-se de que seu middleware CORS seja executado antes de suas rotas ou manipule OPTIONS explicitamente e retorne 204.

P: Por que credenciais: true rompem com origem ‘*’?
R: Os navegadores proíbem o envio de credenciais (cookies, auth) quando a origem permitida é o curinga*. Especifique a origem exata quando precisar de credenciais.

P: O cabeçalho está lá, mas ainda falha. Por que?
R: Verifique se a origem corresponde exatamente (protocolo, domínio, porta), se o preflight OPTIONS foi tratado e se um proxy ou CDN na frente não está removendo o cabeçalho. Inspecione os cabeçalhos de resposta reais na guia Rede.

Conclusão

O erro “Nenhum cabeçalho Access-Control-Allow-Origin está presente” significa que o navegador bloqueou uma resposta de origem cruzada porque oservidor não permitiu sua origem. A correção está sempre no servidor:envie o corretoAccess-Control-Allow-Origin cabeçalho, manipule a simulação OPTIONS, corresponda exatamente à origem e nunca use um curinga com credenciais. Para desenvolvimento local, um proxy dev evita o problema de forma limpa. Depois que o servidor retornar os cabeçalhos corretos para sua origem exata e responder às solicitações de comprovação, o erro desaparecerá e suas solicitações serão processadas.