SRI (Subresource Integrity) — защита от supply-chain атак [2026]

Q: Нужно ли мне SRI (Subresource Integrity)?

См. раздел применения выше. Для быстрой проверки — используйте нашу форму.

Igor Verentsov

SRI (Subresource Integrity): определение, применение и примеры

Автор: Igor Verentsov · Обновлено 23 мая 2026

Коротко:

SRI (Subresource Integrity) — защита от компрометации CDN. В <script src="..." integrity="sha384-..."> атрибут integrity содержит hash ожидаемого содержимого. Если CDN подменит файл (supply-chain атака), hash не совпадёт и браузер не выполнит скрипт. Обязательно для всех внешних CDN-ресурсов.

Бесплатный онлайн-инструмент — сканер безопасности сайта: результат мгновенно, без регистрации.

Проверить безопасность сайта →

Что такое SRI (Subresource Integrity)

Проверить SRI (Subresource Integrity) онлайн

Открыть инструмент →

Принцип работы SRI

Принцип работы SRI заключается в проверке целостности загружаемых ресурсов с помощью хеш-значений (hash). В атрибуте integrity тега <script src="..." integrity="sha384-..."> указывается хеш ожидаемого содержимого файла. Когда браузер загружает ресурс, он сравнивает указанный хеш с хешем загруженного файла. Если хеши совпадают, ресурс считается достоверным, и браузер выполняет его. В случае подмены файла (supply-chain атака), хеш не совпадёт, и браузер не выполнит скрипт, предотвращая выполнение вредоносного кода.

Этот механизм обеспечивает дополнительный уровень защиты от атак, направленных на подмену файлов на этапе их доставки через CDN. Для реализации SRI необходимо указать соответствующий хеш в атрибуте integrity и убедиться, что все внешние CDN-ресурсы используют этот атрибут.

Примеры использования SRI

Примеры использования SRI включают защиту внешних скриптов, стилей и других ресурсов, загружаемых с помощью тегов <script>, <link> и других. Например, для защиты внешнего скрипта можно использовать следующий код:

<script src="https://example.com/script.js" integrity="sha384-XXXXXX"></script>

Здесь src указывает на URL скрипта, а integrity содержит хеш ожидаемого содержимого. Аналогично можно защитить стили и другие ресурсы.

Важно отметить, что SRI может быть использован не только для защиты внешних ресурсов, но и для внутренних, если есть риск их подмены.

Преимущества и недостатки SRI

Преимущества использования SRI включают:

Повышение безопасности веб-приложений за счёт предотвращения выполнения вредоносного кода.
Защита от supply-chain атак, направленных на подмену файлов на этапе их доставки.
Упрощение процесса проверки целостности ресурсов.

Однако у SRI есть и недостатки:

Необходимость генерации и хранения хешей для всех используемых ресурсов.
Возможность ошибок при указании неверных хешей, что может привести к неработоспособности приложений.
Ограничения на использование некоторых CDN-сервисов, которые могут не поддерживать SRI.

Несмотря на некоторые недостатки, SRI является важным инструментом для обеспечения безопасности веб-приложений и защиты от supply-chain атак.

ЗаголовкиCSP, HSTS, X-Frame-Options и др.

SSL/TLSШифрование и сертификат

КонфигурацияСерверные настройки и утечки

Оценка A-FОбщий балл безопасности

Почему нам доверяют

OWASP

рекомендации

15+

заголовков безопасности

<2с

результат

A–F

оценка безопасности

Как это работает

Введите URL сайта

Анализ заголовков безопасности

Получите оценку A–F

Что проверяет анализ безопасности?

Инструмент проверяет HTTP-заголовки безопасности, конфигурацию SSL/TLS, утечки серверной информации и защиту от распространённых атак (XSS, clickjacking, MIMEsniffing). Оценка от A до F показывает общий уровень защиты.

Анализ заголовков

Проверка Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy и других.

Проверка SSL

Версия TLS, срок сертификата, цепочка доверия, поддержка HSTS.

Обнаружение утечек

Поиск раскрытых серверных версий, debug-режимов, открытых конфигов и директорий.

Отчёт с рекомендациями

Детальный отчёт с объяснением каждой проблемы и конкретными шагами для исправления.

Кому это нужно

Специалисты по безопасности

аудит HTTP-заголовков

DevOps

проверка конфигурации

Разработчики

CSP и HSTS настройка

Аудиторы

соответствие стандартам

Частые ошибки

❌

Нет Content-Security-PolicyCSP — главная защита от XSS. Без него инъекция скриптов значительно проще.

❌

Нет заголовка HSTSБез HSTS возможна downgrade-атака с HTTPS на HTTP. Включите Strict-Transport-Security.

❌

Server header раскрывает версиюServer: Apache/2.4.52 помогает атакующим подобрать эксплойт. Скройте версию.

❌

X-Frame-Options не установленСайт можно встроить в iframe для clickjacking-атаки. Установите DENY или SAMEORIGIN.

❌

Нет X-Content-Type-OptionsБез nosniff браузер может интерпретировать файлы неправильно (MIME sniffing).

Лучшие практики

✓

Начните с базовых заголовковМинимум: HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy. Займёт 5 минут.

✓

Внедрите CSP постепенноНачните с Content-Security-Policy-Report-Only, мониторьте нарушения, затем включите.

✓

Скройте серверные заголовкиУдалите Server, X-Powered-By, X-AspNet-Version из ответов.

✓

Настройте Permissions-PolicyОграничьте доступ к камере, микрофону, геолокации — только то, что реально используется.

✓

Проверяйте после каждого деплояЗаголовки безопасности могут быть перезаписаны при обновлении конфигурации сервера.

Получите больше с бесплатным аккаунтом

История security-проверок и мониторинг HTTP-заголовков безопасности.

Зарегистрироваться (FREE)

Больше по теме

Гайды

Глоссарий

Исследования

Альтернативы

Часто задаваемые вопросы

Нужно ли мне SRI (Subresource Integrity)?