Erro de CORS entre o seu front end e a sua API: como resolver

«Access to fetch at … has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present». É uma das mensagens mais procuradas por quem separa o site (React, Vue) da API (Node, Python). A resposta curta: o bloqueio é feito pelo navegador, não pelo servidor, e só se levanta se a API disser, em cabeçalhos da resposta, que aquele site de origem pode ler a resposta. O pedido chegou à API; o navegador é que não deixa o seu JavaScript ver o resultado.

O que é uma «origem»

A origem é o conjunto protocolo + domínio + porta. https://yourcompany.com, https://www.yourcompany.com, http://yourcompany.com e https://api.yourcompany.com são quatro origens diferentes. Se o site é servido por uma e a API por outra, é um pedido entre origens, e o navegador exige a autorização. Para pedidos que alteram dados ou levam cabeçalhos próprios, envia primeiro um pedido de «pré-verificação» (OPTIONS); se a API não responde bem a esse, o pedido verdadeiro nem sai.

Pôr a API a autorizar a origem certa

A API é em… Biblioteca Configuração (exemplo)
Express (Node.js) cors (npm install cors) app.use(cors({ origin: "https://yourcompany.com" }))
Flask flask-cors CORS(app, origins=["https://yourcompany.com"])
Django django-cors-headers CORS_ALLOWED_ORIGINS = ["https://yourcompany.com"] e o middleware no topo da lista
FastAPI Vem com o CORSMiddleware app.add_middleware(CORSMiddleware, allow_origins=["https://yourcompany.com"])

Indique a origem exacta do seu site, com o protocolo e sem barra final. Depois reinicie a API: aplicações Node, e as de Python, mantêm o código antigo até serem reiniciadas.

O erro de CORS pode estar a esconder outro. Se a API devolve um 500 ou um 503, a página de erro não leva os cabeçalhos de CORS, e o navegador mostra o erro de CORS em vez do verdadeiro. Antes de mexer na configuração, abra o endereço da API directamente (ou use curl -i) e veja se responde bem. Se não responde, o problema não é CORS: erro 503 numa aplicação Node.js.
Não ponha * por preguiça. Autorizar qualquer origem é aceitável para uma API pública só de leitura. Para uma API com contas, senhas ou cookies, não: abre a porta a qualquer site. Além disso, o navegador rejeita * quando o pedido leva cookies ou credenciais. Liste as origens que usa de facto.
A solução que evita o problema: servir o site e a API na mesma origem, por exemplo a API num caminho /api do mesmo domínio, atrás de um proxy. Sem pedidos entre origens, não há CORS. Num VPS é natural: nginx como proxy inverso.

A API responde ao curl e o navegador continua a bloquear? Diga-nos o domínio do site, o da API e o que a consola do navegador mostra.

Abrir um pedido de suporte

VEJA TAMBÉM

Publicar um site React ou Vue: a pasta de build e o 404 ao atualizar

Correr uma aplicação Flask ou FastAPI

Nginx como proxy inverso à frente de um contentor

PRODUTO RECOMENDADO

Alojamento de sites com cPanel

Domínio e SSL incluídos, cópias diárias e o painel que já conhece. desde R$ 36,30/mês (plano de 3 anos, com cupom)

Ver planos
  • 0 Usuários acharam útil
Esta resposta lhe foi útil?