O que é CORS e como configurá-lo sem abrir brechas

CORS (Cross-Origin Resource Sharing) é um mecanismo de segurança dos navegadores web que utiliza cabeçalhos HTTP para permitir que uma aplicação rodando em uma origem (domínio) acesse recursos de um servidor em uma origem diferente de forma controlada e segura. Para configurá-lo sem abrir brechas, é crucial evitar o uso indiscriminado do curinga `*` em APIs sensíveis, devendo-se especificar apenas as origens confiáveis no cabeçalho Access-Control-Allow-Origin e limitar estritamente os métodos HTTP e as credenciais permitidas.

Principais Aprendizados

• Não é uma proteção do servidor: O CORS é implementado pelo navegador para proteger o usuário, relaxando a Política de Mesma Origem (SOP).
• O curinga é perigoso: Usar Access-Control-Allow-Origin: * em rotas autenticadas expõe sua aplicação a ataques graves.
• Preflight é essencial: Requisições complexas exigem um método OPTIONS prévio para verificar se o servidor aceita a transação.

Entendendo a Raiz: A Política de Mesma Origem (SOP)

Antes de entender o CORS, precisamos falar sobre o motivo de sua existência: a Same-Origin Policy (SOP). Trata-se de um conceito fundamental de segurança na web. Segundo a documentação oficial da MDN Web Docs da Mozilla, a SOP restringe como um documento ou script carregado por uma origem pode interagir com um recurso de outra origem.

Sem a SOP, um script malicioso em um site de terceiros poderia fazer requisições livremente para o site do seu banco e ler seus dados, aproveitando que você já está logado. É por isso que entender como os cookies, sessões e tokens trafegam é vital para a segurança.

O que significa CORS (Cross-Origin Resource Sharing)?

O CORS surge como a exceção oficial à regra da SOP. À medida que a web evoluiu, aplicações modernas (como SPAs em React ou Angular) passaram a precisar consumir APIs hospedadas em domínios diferentes (ex: meusite.com consumindo api.meusite.com). O CORS fornece uma maneira padronizada para o servidor dizer ao navegador: "Tudo bem, eu confio nessa outra origem e permito que ela leia minha resposta".

Como o CORS funciona na Prática: O Preflight Request

Para requisições simples (como um GET básico), o navegador faz o pedido, recebe a resposta e verifica o cabeçalho Access-Control-Allow-Origin. Se a origem não bater, o navegador descarta a resposta e exibe o temido erro de CORS no console.

No entanto, para requisições complexas (que usam métodos como PUT, DELETE, ou cabeçalhos customizados como Authorization), o navegador realiza um Preflight Request. Ele envia uma requisição prévia usando o método OPTIONS para perguntar ao servidor: "Quais métodos e origens você aceita?". Só após receber sinal verde do servidor é que a requisição real é enviada.

O Perigo do Curinga: Por que evitar o `*`

É muito comum que desenvolvedores, frustrados com erros de bloqueio no console, configurem suas APIs para retornar Access-Control-Allow-Origin: *. Isso significa que qualquer site na internet pode ler as respostas daquela API.

De acordo com diretrizes da Fundação OWASP, falhas na configuração de CORS estão entre os erros mais críticos em ambientes modernos. Durante a execução de um pentest de API, essa é uma das primeiras vulnerabilidades procuradas pelos auditores, pois pode facilitar o roubo de dados sensíveis se combinada com outras brechas.

Como Configurar o CORS Corretamente (Melhores Práticas)

Para garantir que sua aplicação esteja funcional e blindada, você deve tratar a configuração de CORS com a mesma seriedade com que trata outros cabeçalhos de segurança HTTP. Siga estas diretrizes:

1. Especifique as Origens Exatas (Whitelist)

Em vez de usar o curinga, crie uma lista de domínios permitidos (whitelist) no seu backend. Quando uma requisição chegar, o servidor deve verificar se o cabeçalho Origin da requisição está na lista. Se estiver, ele reflete essa origem no Access-Control-Allow-Origin da resposta.

2. Cuidado redobrado com o Allow-Credentials

Se a sua aplicação precisa enviar cookies de autenticação ou cabeçalhos de autorização, você precisará configurar Access-Control-Allow-Credentials: true. Atenção: Os navegadores proíbem estritamente o uso do curinga * quando as credenciais estão ativadas. Você é obrigado a especificar a origem exata, caso contrário, a requisição falhará.

3. Limite os Métodos e Cabeçalhos Permitidos

Não libere métodos HTTP que sua API não utiliza. Use o cabeçalho Access-Control-Allow-Methods para especificar apenas o necessário, como GET, POST, OPTIONS. Faça o mesmo para os cabeçalhos através do Access-Control-Allow-Headers.

Perguntas Frequentes

O CORS protege o servidor contra ataques?

Não. O CORS é um mecanismo de proteção do navegador (cliente). Ferramentas como Postman, cURL ou scripts em Python ignoram completamente o CORS, pois não são navegadores. A proteção real do servidor deve ser feita via autenticação, autorização e firewalls.

Por que meu Postman funciona, mas o navegador dá erro de CORS?

Porque o Postman não implementa a Política de Mesma Origem (SOP). Ele faz a requisição diretamente ao servidor e lê a resposta sem se importar com a origem. O navegador, por outro lado, verifica ativamente os cabeçalhos de CORS para proteger o usuário.

Como resolver o erro 'Blocked by CORS policy' no frontend?

O erro não pode ser resolvido apenas no frontend. Você precisa configurar o servidor (backend) para incluir a origem do seu frontend na whitelist do cabeçalho Access-Control-Allow-Origin. Em ambiente de desenvolvimento local (localhost), você pode usar proxies no Webpack ou Vite para contornar temporariamente o bloqueio.