Marcio Cunha

O que é CORS e como resolver erros de bloqueio no navegador

Entenda a política de mesma origem e aprenda a configurar seus cabeçalhos HTTP para parar de sofrer com erros de bloqueio CORS no seu site.

Marcio Cunha•3 min
Também disponível em:EnglishEspañol
Resumo
  • A política de mesma origem protege o usuário impedindo que scripts maliciosos acessem dados sensíveis de outras abas.
  • O navegador bloqueia requisições cross-origin quando o servidor não envia a permissão explícita no cabeçalho Access-Control-Allow-Origin.
  • Requisições complexas disparam automaticamente um preflight request para verificar se a operação é segura antes de executar.
  • Configurar o CORS no servidor exige mapear as origens permitidas, métodos de requisição e cabeçalhos autorizados.
  • Erros de CORS não significam falhas no código, mas sim uma camada de segurança do navegador funcionando conforme o esperado.

Por que o navegador bloqueia requisições cross-origin?

Você já se deparou com aquele erro temido no console do desenvolvedor dizendo que a requisição foi bloqueada por uma política CORS? Isso acontece por causa da Same-Origin Policy (SOP), uma medida de segurança fundamental que proíbe que um script executando em um domínio tente ler dados de um domínio diferente. Sem essa proteção, qualquer site malicioso que você visitasse poderia fazer requisições em seu nome para o seu banco ou e-mail, aproveitando que você já está logado lá. O CORS (Cross-Origin Resource Sharing) nada mais é do que um mecanismo que permite ao servidor dizer ao navegador: 'Ei, eu confio neste domínio externo, pode liberar o acesso'. Quando essa autorização não está presente, o navegador, por segurança, nega o acesso.

Como funcionam as requisições Preflight

Muitas pessoas acham que o CORS é um problema de rede, mas na verdade é uma coreografia entre o browser e o servidor. Quando fazemos requisições simples, como um GET, o navegador dispara o pedido diretamente. Porém, se a requisição é 'complexa' — por exemplo, quando enviamos um JSON em um POST ou incluímos cabeçalhos customizados como tokens de autenticação —, o navegador envia um 'preflight request' antes. Esse pedido usa o método OPTIONS para perguntar ao servidor: 'Posso fazer esta operação específica vinda desta origem?'. Se o servidor responder corretamente, o navegador prossegue com a requisição real.

Como configurar cabeçalhos para autorizar requisições

Resolver erros de CORS exige que o seu backend envie os cabeçalhos de resposta corretos. Não adianta tentar resolver isso com código no frontend, pois o bloqueio acontece dentro da lógica do motor do navegador. Você deve configurar seu servidor para retornar o cabeçalho Access-Control-Allow-Origin, preferencialmente apontando para o domínio específico que deve ter acesso. Para debug, você pode conferir o tráfego usando ferramentas como o cURL, que ajudam a ver quais cabeçalhos o servidor está realmente entregando antes da resposta ser descartada pelo browser.

Access-Control-Allow-Origin: https://seu-site.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization

Se você estiver enfrentando comportamentos estranhos em sua infraestrutura, lembre-se de monitorar os logs do seu servidor web, da mesma forma que faria ao investigar requisições HTTP lentas no Nginx. Muitas vezes, o erro CORS é apenas o sintoma de uma requisição que falhou por um motivo diferente, como um timeout ou um erro 500 no backend. Para aprofundar esses conceitos na prática em produção, confira também nossa análise técnica sobre Como usar o comando dd no Linux para clonar discos com segurança.

Considerações finais sobre segurança e CORS

O maior erro que desenvolvedores cometem ao lidar com CORS é usar o curinga Access-Control-Allow-Origin: *. Embora isso resolva o erro de bloqueio instantaneamente, você acaba abrindo seu servidor para qualquer página da internet. Sempre prefira listar explicitamente as origens permitidas na configuração do seu backend. Além disso, lembre-se que o CORS só protege o usuário dentro do navegador; APIs públicas que não possuem autenticação baseada em sessão, como serviços de dados brutos, podem não precisar dessa proteção tão rígida se forem desenhadas corretamente desde o início.