Аналитика, реклама, чат, платёжные виджеты, библиотеки с CDN. Большинство сайтов при каждом показе страницы загружают код, который они не писали, и этот код выполняется с теми же правами, что и собственные скрипты сайта. В этом руководстве по первичным источникам OWASP и MDN объясняется, как узнать, что именно выполняется, ограничить возможности этого кода и вовремя заметить изменения. Способы атак здесь не описываются.
Почему сторонние скрипты — это риск
Шпаргалка OWASP «Third Party JavaScript Management Cheat Sheet» делит риски встраивания стороннего JavaScript на три группы.
- Потеря контроля над изменениями
- Обычно нет гарантии, что код поставщика останется таким же, как во время разработки и тестирования. Поставщик может выпустить новые функции в любой момент
- Выполнение произвольного кода у пользователей
- Сторонний код редко проверяют перед подключением, и он выполняется с теми же правами, что и пользователь. OWASP также описывает случай, когда домен поставщика истекает, его перерегистрирует кто-то другой и размещает вредоносный код
- Раскрытие информации третьим сторонам
- При загрузке скрипта браузер напрямую обращается к серверам поставщика, и тот получает IP-адрес и cookie, которые установил ранее
Менеджер тегов добавляет ещё один уровень сложности. OWASP поясняет, что возвращаемое менеджером тегов можно изменить в его веб-интерфейсе, и изменение применяется сразу: при следующем показе страницы выполняется уже изменённый код. Поэтому по исходному коду сайта нельзя узнать всё, что на нём реально выполняется.
На этом сайте уже разбирался случай такого типа: инцидент со сторонним скриптом на Polymarket. Проблемой стал код, выполнявшийся на странице, которую смотрел пользователь.
Страница вашего сайта (содержимое, ввод в формы, cookie)
↓ выполняется внутри той же страницы
Ваши скрипты
Вы сами проверяете и раздаёте их
Сторонние скрипты
Поставщик может их изменить. Они могут читать страницу
Формы с отправкой наружу
Ввод уходит на другой источник
↓ чем ограничить
Инвентаризация и удаление
SRI / размещение у себя / CSP script-src и connect-src
CSP form-action
Как защищаться: шесть шагов
Перечислите все выполняющиеся сторонние скрипты
Начните со списка. Включите скрипты, прописанные прямо в HTML, теги, настроенные в менеджере тегов, и всё, что библиотеки или плагины подгружают сами.
Для каждого запишите источник загрузки, чей это сервис, зачем его добавили, на каких страницах он работает и кто и как отключит его при проблеме. Перечислите также iframe, изображения и другие ресурсы, обращающиеся к внешним серверам: тогда список сразу пригодится для настройки CSP.
Уберите неиспользуемое и сократите набор на важных страницах
Всё в списке без понятного назначения или без владельца — кандидат на удаление. Часто остаются теги старых рекламных кампаний и аналитика, от которой уже отказались.
На страницах с ценным вводом — вход, оплата, смена пароля или email, панель администратора — оставьте только необходимое. Тег, добавленный в общий шаблон сайта, попадает и на эти страницы, поэтому решайте, что загружать, для каждого типа страниц. Для виджетов, которым не нужен доступ к странице, OWASP описывает изоляцию в iframe на отдельном домене с атрибутом sandbox.
Ограничьте права публикации в менеджере тегов
OWASP предупреждает, что слой данных (объект со значениями, передаваемыми тегам) не является песочницей, а контейнеры менеджера тегов могут выполнять пользовательский JavaScript и HTML-теги. Рекомендуется ограничить права публикации и проверять изменения так же, как код приложения.
На практике начните с четырёх мер: право публикации — лишь у нескольких человек, двухфакторная аутентификация для аккаунтов менеджера тегов, отключение пользовательских HTML-тегов, если они не нужны, и проверка вторым человеком перед публикацией.
Добавьте SRI к неизменным файлам или раздавайте их со своего сайта
SRI (Subresource Integrity) позволяет указать хеш файла в атрибуте integrity у <script> и подобных элементов; если полученный браузером файл не совпадает, он не загружается. По данным MDN, допустимы хеши sha256, sha384 и sha512, для файла с другого источника поставщик должен разрешать CORS, а в разметку добавляется атрибут crossorigin.
SRI подходит только для файлов с неизменным содержимым, например версионированных библиотек. Для тега аналитики, который поставщик обновляет когда угодно, каждое обновление ломает загрузку. В таком случае раздавайте проверенную копию со своего сайта (то, что OWASP называет in-house mirroring) или не загружайте его на важных страницах. Известные уязвимости библиотек можно проверить, вставив lockfile в Сканер уязвимостей зависимостей.
Ограничьте источники и адресатов через CSP
В Content-Security-Policy разрешите источники из списка шага 1. script-src ограничивает, откуда загружаются скрипты; connect-src — куда могут подключаться fetch, XMLHttpRequest, WebSocket, EventSource, sendBeacon и подобные API (MDN).
form-action, который ограничивает адреса отправки форм, не наследует default-src. MDN указывает, что без него разрешено всё. Если формы отправляются только на ваш сайт, задайте form-action 'self' явно.
Немедленное применение новой политики может сломать нужные функции, поэтому сначала соберите отчёты о нарушениях через Content-Security-Policy-Report-Only. MDN отмечает, что отчёты отправляются только при указании report-to, а этот заголовок не поддерживается в элементе <meta> (устаревшая директива report-uri тоже работает). Попробовать политики можно в Конструкторе / проверке CSP; о заголовках в целом — в материале о выборе заголовков безопасности.
Сделайте изменения заметными и заранее решите, как отключать скрипты
Сторонние скрипты меняются без вашего участия. С фиксированной периодичностью, например раз в месяц, сравнивайте список с тем, что реально выполняется, и разбирайтесь с каждым незнакомым адресатом в отчётах о нарушениях CSP. Подпишитесь на уведомления поставщиков о безопасности.
Запишите, какой тег, кто и с какого экрана отключает при проблеме. Если у вас есть страницы оплаты картой, учтите, что требования PCI DSS v4.0.1 6.4.3 и 11.6.1 о безопасности платёжных страниц действуют с 31 марта 2025 года (PCI SSC). Для мерчантов, проходящих оценку по SAQ A и полностью передавших обработку данных карт соответствующим требованиям третьим сторонам, эти два требования заменены условием допуска: подтвердить, что их сайт не подвержен атакам скриптов, способным повлиять на системы электронной коммерции; сами требования стандарта не меняются.
Что каждая мера предотвращает и чего нет
| Мера | Предотвращает | Не предотвращает | Подходит для |
|---|---|---|---|
| Удаление | Все риски, связанные с этим скриптом | — | Скриптов без понятного назначения или неиспользуемых |
| SRI | Подмену файла при передаче или у поставщика | То, что неподменённый скрипт отправляет при обычной работе. Загрузка ломается при обновлении файла поставщиком | Версионированных неизменных файлов |
| Размещение у себя | Подмену у поставщика | Старые версии остаются, если не обновлять их самому | Проверенных библиотек, которые вы продолжаете использовать |
| CSP | Загрузку с неразрешённых источников, запросы и отправку форм на неразрешённые адреса | Взлом разрешённого источника. Данные, отправляемые на разрешённый адрес | Всех страниц (внедрять постепенно) |
Легко распространяется
- Теги вставлены в общий шаблон сайта
- Публиковать в менеджере тегов могут многие
- CSP нет или в нём нет
form-action - Нет списка сторонних скриптов и согласованного способа их отключения
Под контролем
- Теги загружаются по типам страниц
- Публиковать могут немногие, изменения проверяет второй человек
- CSP закрепляет источники скриптов, адреса подключений и отправки форм
- Список есть и регулярно сверяется с реальностью
Проверьте результат «Проверкой прозрачности сайта»
Когда список готов, сравните его с тем, что действительно есть на странице. Введите URL главной страницы сайта, которым вы управляете, в Проверку прозрачности сайта — она покажет следующее по загруженному HTML.
- Источники внешних скриптов/ресурсов
- Другие источники, на которые ссылаются script, iframe, img и link (stylesheet, preload и подобные). Всё, чего нет в списке шага 1, требует объяснения
- Теги аналитики / рекламы (отслеживание)
- Распространённые сервисы аналитики, рекламы и мониторинга по названию. Название классифицирует адресата и не является оценкой безопасности
- Неизвестные сторонние скрипты (могут читать ввод)
- Скрипты, загружаемые с другого источника. Ни один скрипт не признаётся безопасным из-за известности поставщика
- Формы, отправляющие наружу
- action формы или formaction кнопки, указывающие на другой источник. Если это не задумано, проверьте в первую очередь и закрепите через CSP form-action
- Устанавливает cookie
- Есть ли Set-Cookie в полученном ответе. Cookie, устанавливаемые JavaScript, не проверяются
У инструмента есть ограничения. Он загружает только главную страницу (включая языковые главные и index.html), не выполняет скрипты и не загружает встроенные файлы. Скрипты, которые позже подгружает менеджер тегов, и запросы, возникающие только по нажатию кнопки, ему не видны. Поэтому сделайте также следующее.
- Откройте проверяемую страницу (включая страницы входа и оплаты) и инструменты разработчика браузера
- Включите запись во вкладке Network и поработайте со страницей на тестовых данных
- Найдите запросы к внешним доменам, которых нет в вашем списке
- После настройки CSP убедитесь через Проверку заголовков безопасности, что заголовок действительно отдаётся
Если ваш сайт работает в Японии: правила о внешней передаче
По данным Министерства внутренних дел и коммуникаций Японии (MIC), поправка к Закону о телекоммуникационном бизнесе от июня 2022 года ввела правила, позволяющие пользователям узнавать, когда теги или модули сбора данных передают сведения о них третьим лицам (действуют с 16 июня 2023 года). Правила распространяются на тех, кто ведёт телекоммуникационный бизнес; MIC приводит как основные примеры сервисы обмена сообщениями, социальные сети, поиск и информационные сервисы вроде новостных и агрегирующих сайтов и указывает, что онлайн-продажа собственных товаров, корпоративные сайты и личные блоги не относятся к телекоммуникационному бизнесу и под правила не подпадают.
Если правила применимы, нужно уведомить пользователей или сделать легкодоступной информацию о том, какие данные передаются, кто их обрабатывает и с какой целью. Список из шага 1 — хорошая основа для такого раскрытия. Применимость проверьте по разъяснению и блок-схеме MIC.
Позиция этого сайта: оценивайте скрипт по тому, что он может прочитать на странице, а не по бренду
Проверка сторонних скриптов часто заканчивается выводом «это крупный сервис, значит, всё в порядке». Но первым риском OWASP называет взлом сервера поставщика, а популярный сервис стоит на множестве сайтов, так что последствия взлома расходятся широко.
Поэтому наша «Проверка прозрачности сайта» никогда не помечает скрипт безопасным из-за известности поставщика. Важны три вопроса: на каких страницах выполняется скрипт, что он может там прочитать и за сколько минут вы сможете его отключить.
Источники (первичные)
- OWASP, «Third Party JavaScript Management Cheat Sheet» — cheatsheetseries.owasp.org (три риска, менеджеры тегов, SRI, изоляция в iframe, in-house mirroring)
- MDN, «Subresource Integrity» — developer.mozilla.org (атрибут integrity, допустимые хеши, CORS и атрибут crossorigin)
- MDN, «Content Security Policy (CSP)» — developer.mozilla.org (script-src, проверка в режиме report-only)
- MDN, «CSP: form-action» — developer.mozilla.org (нет запасного значения из default-src)
- MDN, «CSP: connect-src» — developer.mozilla.org (охватываемые API)
- MDN, «Content-Security-Policy-Report-Only» — developer.mozilla.org (нужен report-to; не поддерживается в meta)
- PCI SSC, «Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A» (30 января 2025 года) — blog.pcisecuritystandards.org (требования 6.4.3 и 11.6.1 действуют с 31 марта 2025 года)
- MIC (Япония), «外部送信規律» (на японском) — soumu.go.jp (цель, сфера действия, что раскрывать)
Что прочитать дальше
- Инструменты: Проверка прозрачности сайта / Конструктор / проверка CSP / Проверка заголовков безопасности
- Настройка: Как выбрать заголовки безопасности
- Инциденты: Инцидент со сторонним скриптом на Polymarket
- Глоссарий: что такое XSS / что такое PCI DSS