Resumo

  • O rascunho Origin de janeiro de 2009 propôs informar ao servidor o contexto que disparou uma requisição, inclusive para examinar falsificações entre sites. O RFC 6454, de dezembro de 2011, deu forma precisa à unidade de confiança usada pelo navegador.
  • Esquema, host e porta compõem essa unidade. O caminho fica dentro dela. Uma página enviada por terceiros como HTML ativo no mesmo origin pode receber os privilégios de navegador das páginas do serviço.

O endereço tinha uma parte que não votava

Um site organiza sua administração em /conta e as publicações dos usuários em /envios. A divisão parece clara na árvore de arquivos. O navegador resolve outra questão: de que origin veio cada página? Se esquema, host e porta coincidirem, a resposta é uma só. O nome da pasta não participa da votação.

O RFC 6454, publicado em dezembro de 2011, codificou uma prática que já vinha sendo construída nos navegadores. Uma aplicação costuma ocupar muitas URLs. Isolar cada uma como se fosse um estranho tornaria a cooperação cotidiana penosa. O origin reúne recursos em uma unidade que pode agir em conjunto. A escolha do que entra nessa unidade fica com quem publica.

O contraste dos exemplos do RFC é concreto. Uma página HTTP em example.com e outro caminho no mesmo host com a porta 80 explícita pertencem ao mesmo origin, porque 80 é a porta padrão de HTTP. Outra porta muda a conta. Trocar HTTP por HTTPS muda também: conteúdo recebido pelo canal sem proteção não herda a confiança da versão protegida apenas por usar o mesmo nome de host. Já dois caminhos diferentes permanecem juntos quando os três componentes coincidem.

Conteúdo alheio, chave de casa

É aí que uma decisão editorial vira decisão de segurança. Se alguém envia uma página e o site a serve como HTML capaz de executar código no origin principal, o navegador a trata dentro do contexto desse origin. O RFC destaca a diferença entre tipos de mídia ao discutir material de usuários. O servidor ainda pode exigir autorização para operações específicas; essa exigência opera em outra camada. O navegador não reduz os poderes de uma página porque seu caminho diz /envios.

O Internet-Draft Origin de janeiro de 2009 começava por uma requisição chegando ao servidor. Seu cabeçalho proposto descrevia o contexto que a provocou e podia ajudar na defesa contra requisições forjadas entre sites. Era uma proposta de trabalho, sem a posição de um RFC publicado. Em 2011, o RFC 6454 organizou a noção de origin além do cabeçalho: a mesma unidade orienta decisões do navegador antes da requisição. Quando não há trio comum de esquema, host e porta, a serialização é null. O texto também prevê null para contextos sensíveis à privacidade.

A Recomendação CORS de 2014 usa essa informação para decidir quem poderá ler uma resposta entre sites, e separa essa leitura da autorização dos efeitos de uma requisição. A história da permissão de leitura tem outro protagonista. Nesta, o protagonista é a régua anterior: quem o navegador já considera vizinho de quarto?

O origin poupou os aplicativos de pedir uma nova licença a cada caminho. Em troca, a forma de hospedar HTML de terceiros passou a definir quem divide o quarto.