Resumo

  • Em fevereiro de 2007, um rascunho do W3C já colocava o dono do recurso no centro da permissão de leitura entre sites. O rascunho CORS de março de 2009 detalhou a troca entre a origem da página, a resposta do recurso e o navegador.
  • A recomendação de janeiro de 2014 descreveu Access-Control-Allow-Origin e a checagem do navegador. Algumas requisições exigem OPTIONS preliminar; uma requisição simples pode chegar ao servidor mesmo que seu resultado não seja entregue ao programa da página.

O painel mostra previsão do tempo, mas os números vêm de outro site. A página sabe o endereço. O navegador sabe fazer a viagem. O impasse é o retorno: código de um domínio não recebe automaticamente licença para ler a resposta de outro. CORS deu ao proprietário do recurso um modo de dizer quem pode receber aquela resposta, e ao navegador uma regra para obedecer.

O rascunho do W3C de 15 de fevereiro de 2007, Enabling Read Access for Web Resources, considerava um cabeçalho HTTP ou uma instrução XML para relaxar a barreira de leitura. Experimentava formatos diferentes para indicar anfitriões; ainda era uma bancada de trabalho. A decisão fundamental, porém, já tinha endereço: quem publica o recurso anuncia a permissão. O rascunho CORS de 17 de março de 2009 aproximou essa ideia da conversa conhecida, com Origin na requisição e declarações de permissão na resposta.

Na recomendação do W3C de 16 de janeiro de 2014, o recurso pode responder com Access-Control-Allow-Origin e nomear a origem que deseja atender. O navegador compara esse nome com o da página solicitante antes de lhe disponibilizar o conteúdo. O caractere * serve para compartilhamento amplo sem credenciais. Quando há credenciais, a regra exige uma origem correspondente e Access-Control-Allow-Credentials: true. Uma placa de «entrada livre» e um convite com nome não autorizam a mesma visita.

Há visitas que pedem uma ligação antes. Métodos ou cabeçalhos definidos pelo programa fora do conjunto simples podem disparar uma requisição OPTIONS preliminar. Ela pergunta quais métodos e cabeçalhos o destino aceita daquela origem. O navegador avalia a resposta, pode guardá-la por um tempo e só então prossegue. O chamado preflight é uma etapa condicional. Tratá-lo como o ritual de toda requisição entre sites confunde mais do que ajuda.

A distinção essencial é entre chegar e ler. Uma requisição simples pode alcançar o servidor, que pode processá-la, mesmo quando o navegador depois impede o programa de ler a resposta. A discussão de segurança da recomendação separa autorizar a requisição e seus efeitos de autorizar acesso à representação devolvida. Quem opera o servidor continua responsável por decidir se o usuário pode alterar uma conta, enviar dinheiro ou praticar qualquer outra ação. O cabeçalho CORS cuida da entrega da resposta ao programa; não faz a segurança da operação por decreto.

O histórico de publicações do W3C reúne os rascunhos de 2007, o anúncio da recomendação em 2014 e a retirada formal daquele documento em 2020. A história tem um mecanismo bem concreto: o recurso escolhe os leitores da resposta, o navegador confere a escolha, e a página ganha acesso quando recebe convite. O gráfico do tempo finalmente aparece; o vizinho continua dono da casa.