Subresource Integrity (SRI)

Subresource Integrity — это проект: добавляем атрибуты integrity (хеш) и crossorigin к подключаемым сторонним ресурсам (скрипты/стили с CDN, библиотеки), чтобы браузер проверял целостность файла и НЕ выполнял его, если содержимое изменилось (подменено). Честно про область, это ключевое: SRI защищает от КОНКРЕТНОГО риска — подмены/компрометации подключённого стороннего файла (взлом CDN, supply-chain на уровне доставки файла): если файл подменён, хеш не совпадёт и браузер его не выполнит. Это полезная, но УЗКАЯ мера: она НЕ защищает от XSS в вашем коде, от уязвимостей в самой библиотеке (если подменили — не выполнится, но если в оригинале есть дыра, SRI её не закроет), и не заменяет CSP. Честно про ограничение версионирования, важно: SRI работает только для СТАТИЧЕСКИХ, версионированных ресурсов с фиксированным содержимым — если сторонний скрипт автообновляется по тому же URL (как некоторые виджеты/аналитика), хеш перестанет совпадать и ресурс СЛОМАЕТСЯ; поэтому SRI применим не ко всему (например, не к самообновляемым аналитикам) — честно отметим, к чему применимо. Честно про обслуживание: при обновлении библиотеки нужно обновить и хеш, иначе ресурс перестанет грузиться. Честно про доступ: нужен доступ к коду/шаблонам. Честно про эффект: закрывает риск подмены подключённых файлов, рост продаж сам по себе НЕ гарантируем. Важная граница: это SRI (целостность подключённых файлов), а не CSP (754 — источники), не защита от XSS (752) и не аудит библиотек. Представьте: вместо «подменённый на CDN скрипт выполняется у всех» — браузер отвергает изменённый файл. Базовая цена — от 9 000 ₽ за проект; зависит от числа подключаемых ресурсов.

• Сторонние скрипты/стили подключены без проверки целостности.
• Риск выполнения подменённого через CDN/supply-chain кода.
• Нет защиты от компрометации доставки внешних библиотек.
• Не знаете, какие ресурсы можно защитить через SRI.

• Добавление integrity-хешей и crossorigin к статическим ресурсам
• Определение, к каким ресурсам SRI применим (а к каким нет)
• Корректная обработка self-hosted и версионированных файлов
• Учёт самообновляемых ресурсов (где SRI сломает)
• Проверка, что ничего не сломалось
• Рекомендации по обновлению хешей при апдейте библиотек
• Указание границ (узкая мера, не замена CSP/anti-XSS)
• Передача и разбор с вами

• Подменённые подключённые файлы не выполняются
• Защита от компрометации доставки внешних библиотек
• Применено там, где это безопасно (без поломок)
• Узкий, но реальный барьер (вся защита — в связке)

• Инвентаризируем подключаемые ресурсы; собираем доступ к коду
• Добавляем хеши там, где применимо; исключаем самообновляемые
• Проверяем работу, даём рекомендации по обновлению, разбираем с вами

• SRI защитит мой сайт от взлома?

  Только от конкретного риска — подмены/компрометации подключённого стороннего файла (взлом CDN). Это узкая мера: она не защищает от XSS в вашем коде, от дыр в самой библиотеке и не заменяет CSP. Полезно в связке с другими мерами.

• SRI можно повесить на все скрипты?

  Нет. SRI работает только для статических версионированных файлов с фиксированным содержимым. Если сторонний скрипт автообновляется по тому же URL (некоторые аналитики/виджеты), хеш перестанет совпадать и ресурс сломается. Применяем выборочно, к подходящему.

• Что при обновлении библиотеки?

  Нужно обновить и хеш integrity, иначе обновлённый файл не загрузится (хеш не совпадёт). Это обслуживание: при апдейте версий хеши пересчитываются. Мы оставим рекомендации, чтобы это не сломало сайт.