Como Implementar o Bloqueio de Origens Não Autorizadas com CORS

Proteger APIs e sistemas web de invasões não é opção, é um compromisso para todos nós que desenvolvemos software. O bloqueio de origens não autorizadas é um dos pilares básicos dessa segurança, e o CORS, quando bem implementado, nos permite proteger dados sensíveis e cumprir legislações como a LGPD. Neste artigo, vamos caminhar juntos por conceitos, exemplos, erros comuns e boas práticas para garantir segurança de dados que nossas aplicações tratem origens cruzadas com o rigor e a responsabilidade que elas exigem.

O que são origens não autorizadas?

Antes de falar sobre as ferramentas e processos, é preciso clareza sobre o conceito que está na base de tudo: origem, no contexto web, significa o trio formado por protocolo (ex: HTTPS), domínio (ex: www.exemplo.com) e porta (ex: 443). Ou seja, cada aplicação acessada tem uma origem única deste tipo.

Quando falamos em “não autorizadas”, nos referimos a origens externas que tentam acessar recursos protegidos no back-end de nossas aplicações, sem termos dado a elas permissão explícita. Este tipo de tentativas não parte sempre de criminosos, mas frequentemente de integrações não previstas, testes fronteiriços, ou, nos piores casos, diretamente de ataques pensados para extrair dados.

Em um mundo cada vez mais conectado por APIs, microserviços e integrações, é comum que diferentes sistemas precisem conversar. Só que essa flexibilidade cria pontos de risco: sites de terceiros podem tentar consumir nossos endpoints, realizar requisições maliciosas ou mesmo roubar informações confidenciais.

Nunca confie em requisições vindas de domínios que não foram explicitamente permitidos no seu sistema.

Por que o bloqueio de domínios desconhecidos é tão importante?

Na apuração recente sobre o crescimento global de ataques cibernéticos, vimos que o Brasil e toda América Latina se tornaram importantes focos de invasões, inclusive em setores críticos como manufatura. Um dos vetores é o acesso de APIs e sistemas por domínios externos sem controle ou auditagem.

Esse risco cresce quando somos surpreendidos por vulnerabilidades exploradas por métodos comuns, como injeção de código (citada entre as falhas mais exploradas). Um simples endpoint exposto a todos os domínios abre brecha para ataques automatizados, fuzzing, brute-force em APIs privadas e acesso a recursos internos via engenharia reversa.

Exposição de dados pessoais
Danos à imagem da empresa
Quebras de contrato com clientes e fornecedores
Possibilidade de multas pelos órgãos reguladores (LGPD)
Prejuízo material direto por fraude, roubo ou corrupção de dados

Na N2 Code - Software House, lidamos diariamente com projetos que exigem vigilância permanente quanto a essas ameaças. Não se trata só de proteção técnica, mas de preservar a confiança do ecossistema de nossos clientes.

Política de mesma origem e CORS: o que muda?

Quando surgiu, a web já trazia embutido o conceito de política de mesma origem (Same Origin Policy). O navegador, por padrão, bloqueia scripts de diferentes origens tentando acessar dados sensíveis de outra página ou recurso. Ou seja, um site “B” não pode acessar livremente uma URL protegida do site “A”, mesmo se ambos forem hospedados no mesmo servidor, caso sua origem não seja exatamente igual.

Porém, com a evolução dos serviços web, surgiu a necessidade legítima de integrar aplicações de domínios diferentes. É aqui que entra o CORS (Cross-Origin Resource Sharing): um protocolo de cabeçalhos HTTP que define como (e se) recursos de uma origem podem ser requisitados por scripts de outra origem.

O que acontece se ignoramos o CORS?

APIs podem ser consumidas semcontrole, ampliando superfícies de ataque
Informações privadas podem ser transferidas sem registro ou autorização
Cookies de sessão podem ser manipulados, levando a sequestro de contas
Requisições autenticadas podem ser forjadas (ataques CSRF/ XSSI)

O CORS existe para que administremos quem realmente faz parte do nosso ecossistema digital.

Como o CORS controla as permissões de acesso?

O mecanismo CORS trabalha por meio de cabeçalhos HTTP, respondendo às requisições do navegador sobre permissões de acesso. A chave central para o bloqueio de origens indesejadas é o cabeçalho Access-Control-Allow-Origin.

Vamos ver como ele funciona:

O navegador envia uma requisição contendo o cabeçalho Origin, informando o domínio de origem da solicitação.
O servidor, ao reconhecer a origem, responde com o cabeçalho Access-Control-Allow-Origin.
Se a origem estiver autorizada, o navegador permite o acesso; se não estiver, bloqueia a resposta para o script externo.

Permissões mal configuradas nessas respostas podem abrir as portas do seu sistema.

Como configurar cabeçalhos HTTP para aceitar apenas origens permitidas?

A configuração correta dos cabeçalhos CORS é o segredo para garantir que apenas origens autorizadas acessem seus recursos. Veja como estruturamos normalmente esse processo em nossos projetos na N2 Code - Software House:

1. Definição de um allowlist

Montar a lista de domínios que podem acessar nossas rotas sensíveis é o ponto de partida. Essa lista será usada para validar toda requisição cross-origin.

Liste todos os domínios legítimos que suas integrações precisam acessar: ex: https://cliente1.com.br, https://app.n2code.com
Mantenha essa lista curta e sob revisão periódica
Nunca permita caracteres coringa (“*”) indiscriminadamente em produção

2. Implementação dos cabeçalhos dinâmicos

No backend, usamos códigos semelhantes a este (exemplo em Node.js/Express):

const ALLOWLIST = ['https://cliente1.com.br', 'https://app.n2code.com'];app.use((req, res, next) => {  const origin = req.headers.origin;  if (ALLOWLIST.includes(origin)) {    res.setHeader('Access-Control-Allow-Origin', origin);  }  next();});

Sempre retorne apenas a origem permitida, nunca a lista completa. Evite códigos que retornem * ou múltiplas origens separadas por vírgula, pois o navegador irá recusar esse formato.

3. Outros cabeçalhos CORS relevantes

Além do cabeçalho principal, podemos (e devemos) ajustar outros conforme o tipo de acesso:

Access-Control-Allow-Methods: define quais métodos HTTP são permitidos (GET, POST, etc.)
Access-Control-Allow-Headers: especifica quais cabeçalhos customizados podem ser enviados na requisição
Access-Control-Allow-Credentials: habilita ou bloqueia envio de cookies/autenticação cross-origin
Access-Control-Max-Age: tempo que o navegador pode guardar a permissão (reduzindo consultas repetidas)

Configure sempre o mínimo necessário, nunca além, para reduzir a superfície de ataque.

O papel dos preflight requests na segurança do CORS

Em acessos mais sensíveis, como requisições que alteram dados ou envolvem credenciais, o navegador faz uma etapa extra antes de liberar a comunicação: o chamado preflight request. Ele envia uma requisição do tipo OPTIONS ao servidor, perguntando explicitamente se a ação desejada é permitida.

Preflight é uma dupla checagem de portas antes de liberar o acesso.

Se o servidor responde com os cabeçalhos adequados, o navegador então faz a requisição original. Caso contrário, o acesso é bloqueado já no navegador, reduzindo também abusos por parte de scripts maliciosos.

Essas etapas automáticas só têm efeito real se a configuração dos cabeçalhos for detalhada e revista rotineiramente. Ignorar o preflight pode permitir comportamentos inesperados em navegadores mais permissivos ou APIs expostas.

Integração do CORS nas rotinas ágeis de desenvolvimento

Quando estamos construindo sistemas sob demanda, como costumamos fazer na N2 Code - Software House, a integração do CORS já faz parte dos nossos primeiros builds e revisões de segurança. Nossa sugestão para equipes que buscam agilidade sem abrir mão da proteção:

Defina allowlists ainda nos ambientes de desenvolvimento e mantenha-as versionadas
Automatize a revisão das origens utilizando scripts ou middlewares integrados ao pipeline de CI/CD
Inclua checklists de CORS em revisões de código (code review) e pull requests
Realize testes simulando tentativas de acesso de domínios “falsos” ou simulados, usando ferramentas como Postman, Insomnia ou ambientes de homologação

Ao tratar CORS desde os primeiros estágios, reduzimos retrabalho e protegemos as APIs desde o início de cada projeto.

Melhores práticas para bloquear acessos externos indesejados

A experiência mostra que a negligência de pequenos detalhes pode transformar uma configuração aparentemente segura em um convite aberto a invasores. Veja práticas que adotamos e recomendamos:

Permita apenas domínios estritamente necessários em produção
Evite o uso de comodines (*), exceto quando realmente inevitável e apenas para recursos não sensíveis
Reavalie periodicamente a lista de origens confiáveis
Se possível, registre os acessos autorizados e mantenha logs para auditoria
Impeça que endpoints internos ou administrativos sejam expostos por CORS
Implemente políticas complementares como rate limiting e autenticação JWT
Mantenha documentação clara do fluxo de liberação de novas origens

Quando necessário remover ou alterar uma origem da allowlist, avalie impactos e comunique aos stakeholders para evitar que integrações legítimas sejam interrompidas.

Impacto da LGPD e privacidade das APIs

Com a entrada em vigor da Lei Geral de Proteção de Dados (LGPD), cabe a cada responsável por aplicações web garantir que dados pessoais não sejam transferidos de forma descontrolada para terceiros.

Na N2 Code - Software House, consideramos o bloqueio criterioso de origens via CORS uma peça-chave para a conformidade:

Evita que dados trafeguem para domínios não auditados
Garante rastreabilidade sobre integração de informações críticas
Minimiza exposição de endpoints que poderiam resultar em vazamento de dados sensíveis

A não conformidade com LGPD pode gerar multas altíssimas e, pior: perda de credibilidade.

Além da proteção técnica, o CORS fortalece o registro, a transparência e o controle de processos exigidos por clientes e órgãos fiscalizadores. Por isso, ele não é apenas aliado do time de TI, mas de todas as áreas de negócio e governança.

Monitoramento contínuo de vulnerabilidades em CORS

No cenário atual de ameaças, proteger o sistema hoje não garante sua proteção amanhã. O surgimento contínuo de novas vulnerabilidades, domínios maliciosos e integrações externas exige que mantenhamos vigilância constante sobre como o CORS está sendo aplicado.

Entre as técnicas adotadas por nós para supervisão contínua, destacamos:

Implementação de scanners automatizados que testam diferentes origens
Alertas para tentativas suspeitas de acesso vindas de domínios desconhecidos
Rotinas de compliance para revisão dos cabeçalhos críticos em todas as APIs
Monitoramento de logs buscando padrões de tentativas de exploração (excesso de preflight, tentativas não autorizadas, etc.)
Auditorias periódicas, alinhando as trilhas do CORS às políticas de privacidade e contratos legais

Ferramentas de análise, como as oferecidas pela N2 Code - Software House, atuam proativamente no mapeamento, na análise e no alerta sobre possíveis falhas de permissões em sistemas complexos.

Quando revisar/configurar novamente as permissões?

Nossa sugestão é que revisões aconteçam:

Ao integrar novos sistemas ou parceiros
Quando houver fusões, aquisições ou mudanças de arquitetura
Após atualização de frameworks, dependências ou bibliotecas de segurança
Em resposta a alertas de incidentes, seja por logs internos ou mídia especializada

Na nossa prática, o bloqueio assertivo reduz não só riscos técnicos, mas também ruídos entre times e fornecedores, evitando surpresas de última hora.

Exemplos práticos: bloqueando origens em diferentes cenários

Separamos abaixo exemplos do dia a dia que nos ajudam a visualizar pontos críticos da configuração CORS:

Exemplo 1: API pública com dados não sensíveis

Nesse cenário, podemos liberar o acesso para múltiplos domínios, ou até mesmo utilizar o coringa *, limitando os métodos e evitando inclusão de credenciais.

app.use((req, res, next) => {  res.setHeader('Access-Control-Allow-Origin', '*');  res.setHeader('Access-Control-Allow-Methods', 'GET');  next();});

Jamais use este padrão para APIs protegidas por autenticação de usuário. Exemplo: uma rota pública para consulta de meteorologia.

Exemplo 2: Integrações controladas entre domínios específicos

Imagine que apenas o domínio https://app.n2code.com deve consumir nossos endpoints privados. O código seria:

const whitelist = ['https://app.n2code.com'];app.use((req, res, next) => {  const origin = req.headers.origin;  if (whitelist.includes(origin)) {    res.setHeader('Access-Control-Allow-Origin', origin);    res.setHeader('Access-Control-Allow-Credentials', 'true');  }  next();});

Neste caso, o envio de credenciais está habilitado apenas para usuários legítimos daquele domínio.

Exemplo 3: Excluindo domínios problemáticos

Ao detectar tentativas de acesso vindas de domínios fraudulentos, podemos incluir lógica para bloquear ou até mesmo registrar tentativas suspeitas, desta forma:

const blacklist = ['https://hacker.com', 'https://rouboldados.net'];app.use((req, res, next) => {  const origin = req.headers.origin;  if (blacklist.includes(origin)) {    res.status(403).json({error: "Acesso negado"});    return;  }  next();});

Reforçamos que, sempre que for configurar este tipo de filtro, mantenha notificações para alertar sua equipe de segurança.

Erros comuns que prejudicam a segurança do CORS

Mesmo quem tem experiência pode cometer deslizes que colocam tudo a perder. Veja alguns pontos críticos frequentemente ignorados:

Permitir Access-Control-Allow-Origin: * em roteadores que exigem autenticação
Esquecer de atualizar a allowlist após uma mudança de domínio de parceiro
Configurar múltiplas origens separadas por vírgula (não é aceito pelo padrão do CORS!)
Não tratar corretamente Origem null (tipicamente em extensões de navegador, arquivos locais, e ataques tricked-out)
Ignorar os métodos de requisição na configuração (GET é bem diferente de POST, PUT, DELETE...)
Deixar endpoints críticos de administração expostos a origens cruzadas

Cada erro de configuração pode resultar em um incidente de segurança impactante para sua organização. Não negligencie auditorias.

Caso prático: bloqueio proativo e rastreamento na N2 Code - Software House

Recentemente, desenvolvemos um sistema para um cliente do setor financeiro cuja API de extratos era alvo de tentativas de acesso via domínios não homologados. Aplicando as rotinas de bloqueio de domínio via CORS, baixamos em 89% o volume de requisições externas problemáticas já no primeiro mês.

Além disso, os alertas automatizados implantados em parceria com nosso cliente permitiram identificar domínios desconhecidos tentando acessar a API, o que orientou ajustes dinâmicos na allowlist e ações jurídicas contra domínios maliciosos detectados. Esse tipo de case mostra a força aliada entre tecnologia, governança e monitoramento contínuo para combater ataques.

Checklist rápido para revisão do seu CORS

Separamos uma lista para orientar revisões regulares ou aquela última checada antes do go-live:

A allowlist está atualizada e documentada?
Existe algum endpoint aceitando qualquer origem por engano?
Métodos HTTP estão restritos exatamente ao necessário?
O envio de cookies e credenciais demanda autenticação apropriada?
Logs de acesso registram tentativas de origem não autorizada?
Todos os domínios admitidos passaram por validação de contrato/confiança?
Alguma mudança recente requere nova revisão do CORS?

Revisão contínua é sinônimo de proteção eficaz contra origens desconhecidas.

Como unir CORS a outras camadas de proteção?

Isolar acessos externos é só uma etapa em uma boa estratégia defensiva. As integrações mais seguras incluem:

Tokenização de acessos (JWT, OAuth, etc.)
Restrição de IPs e VPNs para parceiros chave
Rate limiting para impedir exploração automática de APIs
Firewall de aplicação (WAF) com regras de deep packet inspection

Um CORS bem feito não substitui autenticação forte, criptografia e revisão manual dos contratos de integração. Pense sempre em camadas defensivas.

Desafios e tendências futuras em bloqueio de origens não confiáveis

A evolução dos browsers, novas regulamentações sobre dados e padrões como SameSite para cookies são apenas alguns exemplos de mudanças que afetam o modo como tratamos a confiança entre domínios. No nosso dia a dia percebemos:

Adoção crescente de Single Page Applications com APIs headless exigindo controles rígidos de CORS
Movimento das equipes de segurança para automação de testes e auditorias constantes dos cabeçalhos de permissão
Integrações webhook e callback, onde a confiança de terceiros depende de revisão exaustiva da origem
Uso de frameworks que já entregam middlewares com segurança CORS, mas que exigem personalização detalhada e atualização constante

O bloqueio de domínios não autorizados seguirá evoluindo junto com o aumento dos ataques e com as demandas cada vez mais rígidas da legislação.

Nossa experiência e referências para aprofundar

Compartilhamos regularmente conteúdos sobre segurança, privacidade e inovação em desenvolvimento web. Para aprofundar o tema, recomendamos a leitura de nosso acervo dedicado a desenvolvimento web e os artigos do nosso especialista Gustavo Pires, que aborda desde técnicas básicas de bloqueio de origens até integrações complexas de APIs.

Para exemplos práticos de casos reais, sugerimos estes conteúdos:

Conclusão: adote o bloqueio de origens desconhecidas como rotina de segurança

O bloqueio inteligente de acessos por CORS é uma das defesas que mais traz benefícios rápidos e efetivos para qualquer aplicação web, seja ela pública ou privada. Integrar CORS ao ciclo de desenvolvimento e revisão contínua dos projetos reduz riscos, amplia a confiança do mercado e garante aderência a normas como a LGPD.

Adotar boas práticas de permissão de domínios nunca será excesso de zelo, é sinal de maturidade de um time preocupado com a longevidade do negócio.

Se você busca projetos personalizados, ferramentas de auditoria automatizadas ou orientações em boas práticas de segurança para APIs, conheça as soluções e o time da N2 Code - Software House. Entre em contato conosco e garanta que as próximas linhas de código subidas em produção estejam sempre protegidas.

Perguntas frequentes sobre bloqueio de origens com CORS

O que significa bloqueio de origens no CORS?

Bloqueio de origens no contexto do CORS é a prática de impedir que domínios não aprovados consumam recursos das suas APIs e aplicações web, criando uma barreira entre sistemas confiáveis e externos. Isso é feito respondendo às requisições vindas de diferentes origens apenas com permissões explícitas nos cabeçalhos HTTP.

Como funciona o bloqueio de origens não autorizadas?

Quando um navegador faz uma requisição para um recurso com uma origem diferente, ele envia um cabeçalho Origin. O servidor valida essa origem e, se não estiver na lista de confiança (allowlist), responde sem o cabeçalho Access-Control-Allow-Origin, impedindo que o navegador permita uso dos dados pela aplicação externa. O bloqueio acontece diretamente no browser, reduzindo a superfície de exposição do seu sistema.

Quais riscos ao não bloquear origens desconhecidas?

Os riscos vão desde vazamento de dados pessoais e sensíveis, passando por ataques de automação de APIs, sequestro de sessão (CSRF), até comprometimento de credenciais e multas decorrentes do descumprimento da LGPD. Além disso, sistemas abertos a qualquer origem acabam sendo alvo de bots e técnicas de fuzzing que buscam vulnerabilidades conhecidas.

Como implementar o bloqueio com CORS na prática?

Para implementar, defina uma allowlist com os domínios aprovados, configure no backend apenas as permissões necessárias (por domínio e método HTTP) e realize verificações rotineiras dessas políticas. Automatize alertas para acesso suspeito e mantenha logs detalhados de tentativas de requisição de domínios não permitidos. Não utilize permissões genéricas, revise sempre as origens válidas para evitar acessos indevidos.

Bloquear origens afeta a performance do site?

Normalmente, o bloqueio de origens por CORS não impacta a performance do site, pois envolve apenas a checagem de domínios e resposta de cabeçalhos no servidor. Contudo, em APIs altamente acessadas, recomenda-se implementar revisões rápidas de listas de permissão e testar eventuais delays extras em preflight requests.