Glossário
O que é CORS — como funciona e o que uma configuração incorreta expõe
O CORS controla se o JavaScript de outra origem pode ler as respostas da sua API. Uma configuração incorreta deixa um site de terceiros ler dados de um usuário logado. Como funciona e configurar com segurança (lista de permissões).
"Adicionei Access-Control-Allow-Origin e a API funcionou — isso é seguro?" O CORS não é "adicionar e está pronto"; o ponto é estreitar quem você permite. Veja como ele funciona e como configurá-lo com segurança (sem passos de ataque).
Primeiro, como funciona
Os navegadores aplicam uma política de mesma origem: o JS de outra origem não pode ler livremente as respostas de outro site. O CORS existe para abrir essa exceção apenas às partes que o servidor permite explicitamente.
| Cabeçalho de resposta | Significado |
|---|---|
Access-Control-Allow-Origin | Quais origens podem ler a resposta |
Access-Control-Allow-Credentials | Se requisições com credenciais (cookies) são permitidas |
Access-Control-Allow-Methods / -Headers | Quais métodos/cabeçalhos HTTP são permitidos |
O ponto: o CORS está do lado do "afrouxar a restrição". Afrouxe-o errado e dados que não deveriam ser legíveis se tornam legíveis por terceiros.
O que torna uma configuração perigosa
Configurações perigosas (comuns)
- Refletir a Origin da requisição de volta como permitida
Access-Control-Allow-Origin: *mais permitir credenciais- Abrir APIs amplamente para origem cruzada que não precisam disso
Configurações seguras
- Uma lista de permissões (apenas origens fixas e confiáveis)
- Negar por padrão para todo o resto
- Para requisições com credenciais, uma origem específica, não
*
Os fundamentos de uma configuração segura
Use uma lista de permissões (o mais importante)
Não reflita a Origin cegamente
Origin da requisição diretamente em Access-Control-Allow-Origin. Retorne-a apenas quando ela corresponder à lista de permissões.Nunca use * com credenciais
Access-Control-Allow-Origin: * com Allow-Credentials: true. Nomeie uma origem específica em vez disso.Minimize o que você abre
A visão deste site: o CORS é 'como você afrouxa', não 'defesa' — estreite a quem você abre
Uma crença equivocada comum é "adicionar cabeçalhos CORS torna seguro". É o contrário — o CORS afrouxa a restrição do navegador. Então o truque não é "como você adiciona", mas "minimizar a quem, e até onde, você abre." Neste site separamos dados que podem ser lidos externamente dos que não podem, e recomendamos negar por padrão, com uma lista de permissões abrindo apenas as exceções. Note que XSS (que quebra a premissa de leitura) e CSRF (que tem como alvo mudanças de estado) são bugs separados — o CORS sozinho não cobre tudo.
Leia a seguir
- Glossário: O que é XSS · O que é CSRF
- Verifique: Verificador de cabeçalhos de segurança
FAQ
QPara que serve o CORS?
Os navegadores aplicam uma política de mesma origem: o JavaScript de uma origem (site) não pode ler livremente as respostas de outro site. O CORS (Cross-Origin Resource Sharing) é como um servidor abre essa exceção — mas apenas para as partes que ele permite explicitamente. Cabeçalhos de resposta como Access-Control-Allow-Origin declaram quais origens podem ler a resposta.
QO que uma configuração incorreta de CORS expõe?
Permissões frouxas demais podem deixar o site de um atacante ler, via JavaScript, as respostas de API de um usuário logado. Casos clássicos: refletir de volta como permitida a Origin da requisição, ou definir Access-Control-Allow-Origin como * enquanto também permite credenciais (cookies). O resultado é que dados pessoais ou tokens podem chegar a um site de terceiros.
QQual é a base de uma configuração segura?
Uma lista de permissões. Permita apenas origens confiáveis previamente decididas e negue o resto (negar por padrão). Não reflita cegamente a Origin da requisição. Para requisições com credenciais, não use * em Access-Control-Allow-Origin — nomeie uma origem específica. E exponha apenas os endpoints que genuinamente precisam ser de origem cruzada.