Resumo

  • O primeiro rascunho público de Subresource Integrity saiu em 18 de março de 2014 e propôs conferir recursos recebidos com resumos criptográficos. Seu conjunto inicial de elementos possíveis era mais amplo que o da Recomendação final.
  • A Recomendação do W3C de 23 de junho de 2016 definiu o atributo integrity para scripts e links de folhas de estilo. O navegador compara a resposta verificável com o resumo esperado e recusa executar ou apresentar um arquivo diferente.

O entregador chegou ao endereço de sempre. Trazia uma caixa com o nome conhecido do script, e a página o recebia todos os dias. Ainda assim, a pergunta decisiva dizia respeito ao conteúdo da caixa. Um JavaScript alterado pode mudar o funcionamento da página; uma folha de estilo alterada pode mudar sua aparência. A URL indica o local da entrega. A digital criptográfica identifica a versão que o editor queria receber.

O primeiro Working Draft público do W3C, de 18 de março de 2014, apresentou a ideia de comparar o recurso obtido com um hash esperado. O rascunho cogitava uma lista extensa de elementos, passando por imagens e quadros além de scripts e estilos. Havia muito material na bancada. Os textos seguintes transformaram a proposta em um mecanismo de aplicação mais delimitada.

No Candidate Recommendation Snapshot de 12 de novembro de 2015, integrity já se concentrava em script e no link que chama uma folha de estilo. A Recomendação de 23 de junho de 2016 manteve esses dois pontos. O autor colocava os metadados do hash ao lado da URL no HTML. O navegador buscava o recurso, calculava o resumo da resposta apta à verificação e comparava os valores. A porta se abria conforme o conteúdo entregue, além do endereço impresso na embalagem.

Os metadados informam a função de hash e o resumo esperado. A Recomendação exigiu suporte a SHA-256, SHA-384 e SHA-512 dos agentes de usuário. Ela também permitiu vários valores de integridade para um recurso, dando prioridade ao algoritmo suportado mais forte. No instante em que um arquivo externo poderia executar código ou modificar o visual da página, o próprio documento declarava exatamente qual versão estava aguardando.

Também importava o tipo de resposta recebido. Uma resposta da mesma origem pode ser examinada. Uma resposta de outra origem pode ser examinada quando o CORS libera o acesso necessário. Uma resposta opaca esconde os dados exigidos pela comparação. O editor precisava combinar o resumo esperado com uma entrega que o navegador conseguisse medir. A conferência faz parte das regras concretas de carregamento da Web.

Se os valores divergem, a Recomendação de 2016 manda o navegador recusar a execução ou apresentação do recurso e retornar um erro de rede. Um evento de erro permite ao autor oferecer uma alternativa conhecida, como uma cópia local. O entregador familiar fica do lado de fora quando chega com a caixa errada. A equipe decide então como manter a tarefa do leitor funcionando.

O histórico de publicações do W3C percorre o primeiro rascunho de 2014, a etapa candidata de 2015 e a Recomendação de 2016. O anúncio de 23 de junho de 2016 descreveu o resultado como uma forma de verificar que o recurso chegou sem manipulação inesperada. O percurso também mostra como a lista inicial de possibilidades se estreitou até scripts e folhas de estilo.

Há uma exigência para qualquer atualização planejada: se o arquivo muda por vontade do editor, o resumo esperado muda com ele. Um hash antigo barrará até uma versão legítima. O autor decide qual conteúdo convidou, o navegador mede o que apareceu. A URL levou o pacote à portaria; a digital disse se era a encomenda certa.