Кратко

  • Первый публичный проект Subresource Integrity вышел 18 марта 2014 года. Он предложил сверять загружаемые ресурсы по криптографическим хешам и рассматривал более широкий круг элементов, чем итоговая Рекомендация.
  • Рекомендация W3C от 23 июня 2016 года определила integrity для скриптов и ссылок на таблицы стилей. Браузер сравнивает пригодный к проверке ответ с ожидаемым хешем и отвергает несовпавший файл.

Курьер нашёл знакомый дом без карты. Скрипт приезжал сюда вчера и позавчера, а адрес на странице оставался прежним. Но в коробке могло лежать новое содержимое. Другой JavaScript меняет действия страницы, другая таблица стилей меняет то, что увидит читатель. URL сообщает место получения. Хеш описывает версию, которую хозяин страницы собирался принять.

Первый публичный рабочий проект W3C от 18 марта 2014 года предложил сравнивать полученный ресурс с заранее известным криптографическим отпечатком. Ранний текст рассматривал широкую компанию HTML-элементов: рядом со скриптами и стилями стояли изображения и фреймы. На чертёжном столе места хватало всем. По мере работы стандарт получил более узкий и определённый вход.

В снимке Candidate Recommendation от 12 ноября 2015 года атрибут integrity сосредоточился на script и link, который подключает таблицу стилей. Рекомендация W3C от 23 июня 2016 года закрепила эту пару. Автор ставит метаданные хеша рядом с URL в HTML. Браузер получает ресурс, вычисляет хеш ответа, который допускает проверку, и сравнивает значение с ожидаемым. Правильный дом ещё не означает правильную посылку.

Метаданные указывают хеш-функцию и ожидаемый результат. Рекомендация потребовала от пользовательских агентов поддержку SHA-256, SHA-384 и SHA-512. Для одного ресурса можно указать несколько значений; среди поддерживаемых алгоритмов приоритет получает самый стойкий. Перед тем как внешний файл станет исполняемым кодом или изменит оформление, документ уже обозначил, какую именно версию он приглашал.

Браузеру нужен доступ к содержимому ответа. Ответ того же происхождения годится для проверки. Ответ с другого происхождения тоже годится, когда CORS разрешает чтение. Непрозрачный ответ скрывает байты, необходимые для сравнения. Издателю требовались и верный ожидаемый хеш, и путь доставки, который позволял провести проверку. Здесь работают реальные правила сетевого запроса.

Если значения расходятся, Рекомендация 2016 года предписывает браузеру отказаться от исполнения или отображения ресурса и выдать сетевую ошибку. Событие ошибки позволяет автору подставить известную запасную копию. Знакомый курьер с чужим содержимым остаётся за порогом. Страница затем решает, как читатель продолжит работу.

История публикаций W3C проводит путь от первого проекта 2014 года через кандидатский этап 2015-го к Рекомендации 2016-го. Объявление W3C от 23 июня 2016 года описало механизм как проверку ресурса на неожиданное изменение при доставке. Сравнение документов показывает и сужение области: от длинного раннего списка элементов к скриптам и ссылкам на стили.

Для команды появляется будничное правило. Если файл меняют сознательно, ожидаемый хеш тоже обновляют. Старое значение остановит нужную новую версию так же решительно, как нежеланную замену. Автор указывает заказ, браузер сверяет товар. URL привёл курьера к дому. Отпечаток рассказал, что у него в коробке.