O CORS é um recurso de segurança implementado pelos navegadores que controla como páginas web de um domínio podem solicitar e interagir com recursos de outro domínio. Ele ajuda a impedir o acesso cross-origin não autorizado, ao mesmo tempo que permite o compartilhamento legítimo de dados entre origens. O CORS usa cabeçalhos HTTP para estabelecer um diálogo entre navegadores e servidores, determinando se as requisições cross-origin devem ser permitidas com base na origem e em outros fatores.
O Cross-Origin Resource Sharing (CORS) é a exceção controlada à same-origin policy. Ele permite que um servidor opte por compartilhar suas respostas com scripts de outras origens ao retornar cabeçalhos HTTP específicos. Para requisições simples, o navegador envia um cabeçalho Origin e verifica o Access-Control-Allow-Origin da resposta antes de deixar o script chamador ler o corpo. Para métodos ou cabeçalhos que poderiam alterar estado, o navegador primeiro envia uma requisição de preflight OPTIONS, e o servidor precisa aprovar o método, os cabeçalhos e a origem. Quando há credenciais envolvidas, como cookies, o servidor precisa definir Access-Control-Allow-Credentials: true e ecoar uma origem específica em vez de um curinga. O navegador impõe tudo isso.
O CORS costuma ser afrouxado até que as requisições parem de falhar, o que desmonta silenciosamente as proteções de mesma origem em torno de endpoints sensíveis. Refletir o cabeçalho Origin da requisição de volta no Access-Control-Allow-Origin enquanto também se permitem credenciais, na prática, deixa qualquer site ler respostas autenticadas em nome de uma vítima logada, expondo dados de conta ou tokens. Confiar em um curinga, em uma regex ampla demais que corresponde a subdomínios controlados pelo atacante ou na origem literal null são erros comuns. Como a falha é invisível no uso normal e só aparece quando explorada, um CORS permissivo em uma API é um vetor real de exposição de dados, e não uma configuração meramente cosmética.
Mantenha uma allowlist explícita de origens confiáveis e compare a Origin recebida com ela de forma exata, em vez de refletir o que quer que chegue. Nunca combine um curinga com requisições que usam credenciais, evite permitir a origem null e restrinja regras permissivas ao conjunto mais estreito de caminhos e métodos que realmente precisam delas. Mantenha o cache de preflight (Access-Control-Max-Age) razoável e reavalie as políticas quando novos subdomínios surgirem. O CORS é um mecanismo neutro da plataforma web, então a defesa principal é a configuração correta do servidor e a revisão; uma camada de monitoramento client-side o complementa ao observar como os scripts de terceiros se comportam, mas o CORS em si pertence aos endpoints que você controla.
Não diretamente. O CORS é imposto pelo navegador e governa se um script pode ler uma resposta de outra origem; ele não impede clientes que não são navegadores, como o curl ou um proxy do lado do servidor, de ler sua API. Ele protege os usuários de terem suas respostas autenticadas lidas por outros sites, não o servidor de ser chamado.
O navegador envia um preflight para requisições que não são simples, por exemplo aquelas que usam PUT ou DELETE, cabeçalhos personalizados ou certos tipos de conteúdo. Ele pergunta ao servidor, via cabeçalhos, se o método, os cabeçalhos e a origem reais são permitidos antes de enviar a requisição de fato, evitando chamadas inesperadas que alteram estado.
We answer client-side security questions every day. Bring yours.