CORS em aplicações web: riscos comuns e configuração segura
CORS é mal compreendido e mal configurado. Veja o que ele realmente faz e como evitar liberar demais.
CORS é um dos temas mais mal compreendidos em segurança web. Muita gente acha que ele protege a API, quando na verdade é um mecanismo do navegador que controla quais origens podem ler respostas de requisições feitas a partir de outra origem. Configurações erradas de CORS são comuns: liberar qualquer origem por conveniência, refletir a origem da requisição sem validar ou combinar origem ampla com credenciais, abrindo brechas reais.
Este guia explica CORS de forma clara e defensiva: o que ele faz e o que não faz, os erros mais comuns e como configurar de maneira segura. O foco é entender o mecanismo para não enfraquecê-lo sem perceber.
O que CORS faz e o que não faz
CORS é aplicado pelo navegador. Ele decide se o JavaScript de uma origem pode ler a resposta de uma requisição a outra origem, com base nos cabeçalhos que o servidor retorna, como Access-Control-Allow-Origin. CORS não é autenticação nem autorização e não protege contra requisições feitas fora do navegador, como por ferramentas de linha de comando. Ele controla leitura entre origens no contexto do navegador, nada além.
Isso significa que CORS não substitui controle de acesso no servidor. A API ainda precisa autenticar e autorizar cada requisição. Confiar no CORS como barreira de segurança do backend é um equívoco que deixa a API exposta a clientes que não são navegadores.
Erros comuns e impacto
O erro mais frequente é liberar qualquer origem com um curinga. Pior ainda é refletir dinamicamente a origem da requisição de volta no cabeçalho sem validar, o que efetivamente permite qualquer site. Quando isso se combina com permitir credenciais, uma página maliciosa pode fazer requisições autenticadas em nome do usuário e ler as respostas, levando a vazamento de dados.
- Não liberar qualquer origem por padrão
- Não refletir a origem da requisição sem validar contra uma lista
- Ter cuidado redobrado ao permitir credenciais entre origens
- Restringir métodos e cabeçalhos permitidos ao necessário
- Lembrar que CORS não substitui autenticação no servidor
Configuração segura e testes
A configuração segura parte de uma lista de origens confiáveis, validando a origem da requisição contra essa lista antes de respondê-la. Permita apenas os métodos e cabeçalhos que a aplicação usa, e seja especialmente conservador ao habilitar credenciais. Teste o comportamento de forma defensiva, verificando como a API responde a origens não autorizadas, sem atacar sistemas de terceiros.
Checklist prático
- Tratar CORS como controle de navegador, não de backend
- Manter autenticação e autorização no servidor independentemente do CORS
- Validar a origem contra uma lista de origens confiáveis
- Não refletir a origem sem validação
- Evitar liberar qualquer origem por padrão
- Ter cautela ao permitir credenciais entre origens
- Restringir métodos e cabeçalhos ao necessário
- Diferenciar configuração de APIs públicas e privadas
- Testar resposta a origens não autorizadas
- Revisar a configuração ao adicionar novos clientes
Boas práticas
- Entenda que CORS protege o navegador, não a API
- Use lista de origens confiáveis em vez de curinga
- Seja conservador ao combinar origem ampla e credenciais
- Mantenha controle de acesso real no servidor
- Restrinja métodos e cabeçalhos ao mínimo
- Revise CORS sempre que a integração mudar
Erros comuns
Liberar qualquer origem com curinga
Qualquer site pode ler respostas no navegador do usuário.
Refletir a origem da requisição sem validar
Equivale a permitir qualquer origem, de forma disfarçada.
Origem ampla combinada com credenciais
Página maliciosa faz requisições autenticadas e lê dados do usuário.
Tratar CORS como segurança do backend
A API fica exposta a clientes que não são navegadores.
Permitir métodos e cabeçalhos amplos
Aumenta a superfície sem necessidade real.
Quando procurar apoio especializado
Avaliar CORS junto da autenticação e da autorização da aplicação é parte dos serviços de Segurança de Aplicações e de Pentest da GUARDIASEC, que testam o comportamento real da API e identificam configurações que ampliam risco.
Perguntas frequentes
CORS protege a minha API?
Não diretamente. CORS é um mecanismo do navegador que controla quais origens podem ler respostas entre origens; ele não autentica nem autoriza, e não afeta requisições feitas fora do navegador. A API ainda precisa de controle de acesso próprio no servidor. CORS bem configurado evita abuso a partir de páginas de terceiros, mas não substitui autenticação.
Posso usar curinga em Access-Control-Allow-Origin?
É arriscado e, combinado com credenciais, perigoso. Liberar qualquer origem permite que sites de terceiros leiam respostas no navegador do usuário. O recomendado é validar a origem da requisição contra uma lista de origens confiáveis e responder apenas às permitidas. Curinga pode ser aceitável apenas para APIs verdadeiramente públicas e sem credenciais.
Refletir a origem da requisição é seguro?
Não, se feito sem validação. Refletir dinamicamente a origem recebida de volta no cabeçalho equivale a permitir qualquer origem, só que de forma disfarçada. O correto é comparar a origem com uma lista de permitidas e só então retorná-la. Refletir sem validar é um dos erros de CORS mais comuns e mais explorados.
CORS e CSP são a mesma coisa?
Não. CORS controla quais origens podem ler respostas de requisições entre origens. CSP, Content Security Policy, controla de onde o navegador pode carregar recursos como scripts e estilos, ajudando contra XSS. São mecanismos diferentes e complementares: um cuida de acesso entre origens, o outro de carregamento de conteúdo na página.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.