Erros de CORS: Como configurar corretamente e evitar brechas na sua API

No cenário atual de desenvolvimento web, garantir a segurança na comunicação entre aplicações frontends e backends não é mais só uma boa prática. É uma necessidade direta para evitar vazamentos de dados, comprometimento de usuários e falhas legais relacionadas à LGPD. Boa parte dessas ameaças se esconde em detalhes aparentemente simples, como a configuração do CORS (Cross-Origin Resource Sharing). Erros nesse ponto representam portas abertas para falhas críticas, principalmente quando lidamos com APIs autenticadas ou expostas à internet. Neste artigo, vamos mostrar o que aprendemos em dezenas de auditorias e explicar como evitar as brechas mais comuns.

Configuração errada de CORS transforma APIs seguras em vulneráveis sem nenhum aviso visível.

O que é a política de mesma origem (Same-Origin Policy)?

Para começar, precisamos partir do conceito base que restringe a comunicação entre sites: a política de mesma origem (Same-Origin Policy, SOP).

Essa política foi criada para proteger usuários impedindo que documentos ou scripts carregados em uma origem possam interagir livremente com recursos de outra. Origem aqui é definida pela combinação de protocolo, domínio e porta.

Por exemplo, imagine que www.exemplo.com roda na porta 443 (https) e api.exemplo.com na porta 8080. Mesmo com domínios semelhantes, eles são origens diferentes.

A SOP bloqueia requisições entre origens, como:

• Leitura de resposta de uma API por um frontend em domínio diferente.
• Acesso ao localStorage ou cookies.
• Execução de certos scripts remotos.

No entanto, isso impede muitas integrações legítimas, por exemplo, um frontend separado consumindo uma API corporativa. Então, surge o CORS para flexibilizar esse bloqueio. Mas ao liberar, precisamos saber exatamente o que estamos autorizando.

Como funciona o CORS na prática?

CORS é um mecanismo que permite controles refinados sobre quais domínios podem fazer requisições a recursos de uma API ou servidor web. Com ele, o backend pode definir quem pode acessar e com quais métodos HTTP.

Quando um frontend faz uma requisição AJAX para uma origem diferente, o navegador verifica as regras de CORS. Se o servidor não retorna os cabeçalhos adequados, a requisição é bloqueada no lado do cliente. Nenhum dado é entregue ao JavaScript de origem diferente.

Exemplo de resposta com CORS permitido:

Access-Control-Allow-Origin: https://app.externo.com

Entre os principais cabeçalhos envolvidos estão:

• Access-Control-Allow-Origin: quais domínios podem acessar.
• Access-Control-Allow-Methods: quais métodos HTTP são aceitos.
• Access-Control-Allow-Headers: quais cabeçalhos personalizados são aceitos.
• Access-Control-Allow-Credentials: se são permitidos cookies/autenticação.

No fluxo real, para métodos sensíveis (POST, PUT, DELETE) ou cabeçalhos personalizados, ocorre um “preflight request” (requisição de verificação), enviando um OPTIONS primeiro para checar as permissões antes da ação principal.

Ferramentas como o Check Site examinam cada uma dessas variáveis para identificar pontos inseguros, como veremos mais à frente.

Por que CORS mal configurado é um risco crítico?

Talvez você já tenha ouvido aquela frase: “Só um detalhe de configuração”. Em segurança, justamente aí mora o perigo.

CORS permite controlar quem acessa API, mas um erro na configuração pode deixar seus dados expostos ao mundo inteiro. E pior: as falhas normalmente só ficam evidentes quando ocorre uma auditoria ou, no pior cenário, após um vazamento.

Listamos abaixo os riscos mais comuns ao configurar CORS sem o devido cuidado:

• Uso de wildcard (*) liberando acesso aberto e indiscriminado.
• Liberar para todos domínios em endpoints autenticados, expondo dados de usuários.
• Permitir credentials (cookies, headers como Authorization) em combinação com origem global.
• Falta de segmentação por ambiente (produção/dev).
• Permitir métodos desnecessários (por exemplo, PUT, DELETE sem uso).
• Header Access-Control-Allow-Headers muito permissivo, aceitando qualquer valor.

Quando CORS está configurado com permissividade exagerada, basta um atacante hospedar um frontend simples em qualquer lugar e acessar seus endpoints protegidos, usando o token de autenticação do próprio usuário legítimo no navegador dele.

O tema é tão preocupante que grandes casos de vazamento começaram exatamente assim: APIs liberadas para “qualquer origem”, incluindo endpoints de cadastro, login ou alterações sensíveis.

O que nunca devemos fazer: wildcard em endpoints autenticados

Imagine o seguinte cenário: sua equipe desenvolveu uma API protegida por JWT, cookies seguros e autenticação robusta. Porém, por pressa para rodar um frontend novo, algum colaborador adiciona:

Access-Control-Allow-Origin: *

Na prática, isso elimina todo o controle de origem, tornando possível que qualquer site da internet faça requisições autenticadas em nome do usuário logado.

O problema cresce quando a configuração abaixo aparece:

Access-Control-Allow-Origin: *Access-Control-Allow-Credentials: true

Nesse caso, além do wildcard, você ainda indica que está tudo certo usar cookies ou headers de sessão/autenticação, algo que os navegadores, felizmente, já bloqueiam se o origin for “*”, mas APIs customizadas podem não perceber.

Fica claro: jamais use wildcard (*) em endpoints onde há autenticação, sessão ou alteração de dados. A recomendação mais segura é sempre especificar explicitamente quais origens são aceitas.

Entendendo implicações práticas em APIs reais

Talvez um dos pontos mais negligenciados em CORS está na integração contínua. Afinal, a cada pull request liberado, novos endpoints podem surgir. E na ânsia de ser prático, muita gente acaba expondo a configuração “*” para todo endpoint, principalmente em microserviços.

Só que cada endpoint é um vetor de ataque em potencial, principalmente quando está autenticado ou manipula dados sensíveis.

Na nossa experiência em auditoria usando Check Site, já encontramos:

• APIs internas liberadas para origens de clientes externos não mapeados.
• Rotas legado esquecidas com permissões amplas.
• Endpoints de administração disponíveis para qualquer origem.
• Endpoints usados em mobile liberando também para web sem querer.

Esses exemplos mostram que a configuração do CORS, longe de ser trivial, precisa ser revisada com frequência, especialmente quando os times são grandes ou atuam em múltiplos projetos.

Boas práticas para configuração segura do CORS

Diante de tantos riscos possíveis, nossa recomendação é seguir algumas boas práticas que realmente fazem diferença na segurança das APIs:

• Liste exatamente os domínios que podem acessar sua API. Prefira sempre Access-Control-Allow-Origin: https://meufrontend.com do que usar *.
• Evite liberar credentials em conjunto com origens amplas.
• Use Access-Control-Allow-Methods restritivo: permita apenas GET, POST, etc., conforme exatamente o necessário.
• Configure Access-Control-Allow-Headers apenas para os headers estritamente usados no frontend.
• Revise endpoints em produção, homologação e desenvolvimento: regras diferentes, ambientes diferentes.
• Automatize auditorias recorrentes, soluções como o módulo CORS do Check Site detectam origens não autorizadas rapidamente.
• Documente o propósito de cada permissão, para novo desenvolvedor entender o porquê da configuração.
• Ao usar proxies ou gateways, certifique-se de que os cabeçalhos CORS não sejam sobrescritos ou liberados globalmente.

Configuração declarativa e documentada impede permissões excessivas por acidente.

Outro ponto é sempre alinhar a configuração do CORS ao modelo de autenticação. Por exemplo, APIs stateless costumam ficar mais expostas, exigindo ainda mais atenção.

Temos em nosso blog diversos conteúdos complementares para quem quer evoluir a maturidade em segurança de APIs. Um bom começo é a leitura do artigo sobre os 17 módulos de segurança que protegem sua aplicação.

Sinal vermelho: sinais de um CORS inseguro

Na prática, alguns sintomas de CORS mal configurado são visíveis antes mesmo de um pentest completo:

• Cabeçalho Access-Control-Allow-Origin devolvido como * para qualquer requisição.
• Endpoints que liberam origem diferente mesmo quando a requisição não deveria ser permitida.
• Resposta do servidor inclui Access-Control-Allow-Credentials: true quando deveria negar.
• Comportamento inconsistente entre ambientes, por deploys manuais ou scripts legados.
• Falhas no controle de CORS configuradas pelo próprio frontend, não pelo backend.

Nesses casos, o ideal é não confiar nos logs apenas, mas testar de fato os endpoints com ferramentas automatizadas. Recomendamos utilizar o módulo “CORS” do Check Site, que simula ataques reais e informa onde estão as brechas de permissões cruzadas.

Bastam alguns minutos de teste para identificar origens não autorizadas e fechar esses buracos.

Como configurar CORS corretamente

Chegou o momento de detalhar como se faz uma configuração segura de CORS.

1. Definindo as origens permitidas

Para cada ambiente (produção, dev, homologação), crie uma whitelist explícita dos domínios autorizados. Não generalize nunca em endpoints autenticados ou que alteram dados.

• Preferir nomes completos, ex: https://app.acesso.com:443
• Evitar wildcards como *.dominio.com, a não ser que todo subdomínio realmente precise do acesso e seja controlado por sua organização.

2. Métodos e headers restritivos

Apenas inclua métodos que possuem uso prático. Se o frontend só faz GET e POST, não permita PUT ou DELETE.

Com os headers, siga mesma ideia: só libere, via Access-Control-Allow-Headers, headers efetivamente usados no frontend.

3. Separação de ambientes

Cada ambiente deve ter regra adaptada. Exemplo prático:

• Produção: liberar só para domínio do frontend real.
• Homologação: liberar para domínios de homolog.
• Desenvolvimento: liberar para localhost:3000 e nunca mais.

4. Testes automatizados e bloqueio rápido

Não basta implementar e esquecer. Automatize o teste sempre que possível. Ferramentas como Check Site trazem vantagem por apontar endpoints esquecidos ou regras globais adicionadas por acidente. Em sprint reviews, inclua como obrigatoriedade validar CORS novo.

5. Documentação da política

Registre quem, por quê e quando pode acessar determinado endpoint. Isso evita permissões abertas no futuro.

Erros comuns e seus desdobramentos reais

Ao revisarmos configurações mundo afora, notamos padrões de erros já conhecidos, porém persistentes:

• Permitir Access-Control-Allow-Origin: * para APIs autenticadas.
• Liberar métodos extensos sem necessidade, como PATCH/DELETE sem uso real.
• Headers Authorization permitidos sem limitação de origem.
• Regra igual para produção e desenvolvimento, expondo builds de teste em produção.
• Esquecer de revisar configurações em endpoints legados ou subserviços escondidos.
• Permitir CORS via frontend (JavaScript) ao invés do backend, o que não serve para nada na prática.

Essas falhas abrem espaço para ataques como Cross-Site Request Forgery (CSRF), session hijacking e vazamento de dados sigilosos. Incidentes desse tipo estão detalhados em seções especializadas no nosso blog, como a de segurança para sistemas.

Integrando auditoria automatizada à rotina de desenvolvimento

Evitar erro humano é missão impossível, especialmente em times ágeis. Por isso, reforçamos que validar CORS deve ser parte do pipeline contínuo.

Auditorias recorrentes detectam permissões amplas, endpoints esquecidos e incoerências entre ambientes.

Com soluções como Check Site, ao rodar o módulo CORS, todo fluxo de permissões é mapeado, e qualquer endpoint que aceite origem global ou headers sensíveis é rapidamente sinalizado para correção.

Essa automação não consome tempo excessivo dos times de backend e DevOps, ajudando a manter a governança mesmo com muitos microserviços ou mudanças rápidas.

Para entender riscos correlatos e abordagens para APIs e sistemas legados, indicamos também conhecer nosso conteúdo sobre processos de análise de segurança para sistemas, softwares e sites.

Por que usar ferramentas especializadas?

Testar CORS manualmente é cansativo e propenso a falhas, ainda mais quando há dezenas de endpoints ou integrações de terceiros.

Com módulos dedicados, como o do Check Site, encontramos rapidamente:

• Permissões cruzadas em endpoints autenticados.
• Riscos resultantes de deploys automáticos sem revisão manual.
• Inconsistências entre ambientes originadas por merges ou scripts antigos.

Essas descobertas permitem ajustar regras antes mesmo do deploy, evitando vulnerabilidades em produção. No contexto de LGPD, também é possível documentar quais domínios acessam dados pessoais, facilitando conformidade.

Não precisa adivinhar se sua configuração CORS está correta: teste e veja o resultado com clareza.

Checklist de revisão para CORS seguro

Antes do deploy final, recomendamos responder as perguntas abaixo:

• Quais endpoints realmente precisam estar públicos?
• Estou limitando a origem permitida ao mínimo necessário?
• Há endpoints autenticados permitindo origens externas?
• As regras mudam entre ambientes?
• Todos métodos HTTP permitidos são usados?
• Headers sensíveis só podem ser enviados por origens autorizadas?
• Cada permissão foi documentada?
• Executamos validação automatizada com uma ferramenta como Check Site?

Essas perguntas ajudam todos a revisar rapidamente pontos críticos antes de liberar para produção, tornando a empresa menos suscetível a incidentes de CORS.

Conclusão: não subestime a configuração de CORS

Ao longo deste artigo, mostramos: CORS parece simples, mas é um dos pontos que mais vemos vulnerabilidades em APIs e sistemas modernos. Pequenos descuidos podem abrir portas para vazamento de dados críticos, exposição à LGPD e ataques cross-site.

Nosso conselho não muda: nunca confie em permissões abertas, revise regularmente e use testes automatizados para validar cada ajuste feito. Ferramentas como as do Check Site vão poupar tempo e garantir que endpoints críticos não estejam expostos para origens não planejadas.

Continue se aprofundando em temas de cibersegurança, conhecendo as tendências em cibersegurança e gestão de incidentes com nossos especialistas.

Não fique na dúvida sobre a configuração do CORS em seu sistema: agende agora uma varredura com o módulo de CORS do Check Site e comprove se suas APIs estão protegidas contra origens indevidas.

Perguntas frequentes sobre erros de CORS

O que é erro de CORS?

Erro de CORS acontece quando uma aplicação web faz uma requisição AJAX para um domínio diferente do backend e o servidor não autoriza essa origem no cabeçalho de resposta. O navegador, então, bloqueia a resposta por padrão devido à política de mesma origem, mostrando um erro ao frontend.

Como configurar CORS na minha API?

Para configurar CORS corretamente, você deve adicionar os cabeçalhos Access-Control-Allow-Origin especificando apenas os domínios autorizados. Também defina métodos e headers permitidos de forma restritiva e evite liberar credentials para origens globais. Use automação para validar configurações periodicamente.

Quais riscos de CORS mal configurado?

CORS mal configurado permite que qualquer site malicioso faça requisições autenticadas à sua API, obtendo dados sensíveis ou executando comandos em nome do usuário logado. Isso pode resultar em vazamentos de dados, violações à privacidade e falha nos controles de acesso.

Como resolver erro de CORS rapidamente?

Primeiro, revise a origem da requisição e ajuste o backend para devolver o cabeçalho Access-Control-Allow-Origin apenas para o domínio correto. Use ferramentas de auditoria automatizada, como o módulo CORS do Check Site, para identificar endpoints problemáticos em minutos.

É seguro desabilitar CORS na API?

Não, desabilitar CORS ou liberar para qualquer origem em APIs autenticadas torna seus endpoints vulneráveis a ataques cross-site. O ideal é limitar rigorosamente quais origens e métodos podem interagir com sua API, conforme práticas mostradas neste artigo.