CSP Report-Only: как проверить скрипты и не сломать сайт

Content Security Policy, или CSP, сообщает браузеру, откуда странице разрешено загружать скрипты, стили, изображения, шрифты, фреймы и другие ресурсы. Правильно настроенная политика создаёт дополнительный барьер для внедрённого JavaScript. Но если сразу включить строгие ограничения на рабочем сайте, вместе с подозрительным кодом могут перестать работать форма заявки, карта, чат, аналитика или оплата.

Безопасный порядок начинается с режима Content-Security-Policy-Report-Only. Браузер отмечает нарушения проектируемой политики, но пока не блокирует ресурсы. Владелец сайта получает карту зависимостей и может проверить её до перехода в принудительный режим.

CSP дополняет защиту, а не заменяет исправление кода

Основная задача CSP — ограничить выполнение и загрузку ресурсов в браузере. Например, строгая политика может разрешать только скрипты с подходящим одноразовым значением nonce или заранее рассчитанным хешем. Случайно внедрённый фрагмент не получит такого разрешения и не выполнится.

Это не означает, что уязвимость можно оставить. web.dev прямо описывает CSP как дополнительный уровень защиты от XSS, а не замену очистке пользовательского ввода и исправлению ошибок. Если сайт принимает опасный HTML, использует устаревший модуль или хранит украденный доступ, одной политикой проблему не закрыть.

Сначала составьте карту ресурсов сайта

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

Для начала выберите ключевые сценарии:

главная, услуги, блог и контакты;
отправка каждой важной формы;
авторизация и личный кабинет, если они есть;
корзина, оплата и возврат с платёжной страницы;
карты, видео, чаты, коллтрекинг и виджеты;
административные страницы, которые относятся к вашей зоне проверки.

Для каждого сценария зафиксируйте домены скриптов, запросов, изображений, шрифтов и фреймов. Отдельно отметьте inline-код, обработчики вроде onclick и вызовы eval(): строгая CSP потребует переработать такие места или явно ослабить политику.

Включите наблюдение без блокировки

Режим Report-Only задаётся HTTP-заголовком. Он не поддерживается через meta так же, как обычная блокирующая политика. Для централизованного сбора браузерных отчётов MDN рекомендует объявить адрес в Reporting-Endpoints и сослаться на него через report-to. Устаревающий report-uri иногда оставляют рядом для совместимости.

Механизм состоит из двух связанных заголовков: Reporting-Endpoints задаёт адрес приёмника, а Content-Security-Policy-Report-Only описывает проверяемые ограничения и ссылается на этот адрес через report-to.

Это схема, а не готовая политика для копирования. Реальному сайту понадобятся отдельные правила для скриптов, соединений, изображений, форм и фреймов. Сам приёмник отчётов нужно защитить: ограничить размер и частоту запросов, проверять формат, не исполнять полученные данные и не складывать без необходимости полные URL с чувствительными параметрами.

Не добавляйте каждый домен в разрешённые

Первые отчёты почти всегда шумные. Нарушение может относиться к нужному ресурсу, старому коду, расширению браузера или действительно незнакомому источнику. Простое добавление всех встреченных доменов превращает политику в формальность.

Разбирайте события по четырём группам:

Нужный ресурс. Подтвердите владельца, назначение и страницу, где он используется.
Устаревшая зависимость. Удалите подключение, если функция больше не нужна.
Шум клиента. Расширения браузера и защитные программы могут создавать события, которых нет у других посетителей.
Неизвестный источник. Проверьте шаблоны, базу данных, менеджер тегов, плагины и историю изменений до выдачи разрешения.

Особенно осторожно относитесь к *, 'unsafe-inline' и 'unsafe-eval'. Иногда они помогают временно сохранить совместимость, но широкое разрешение ослабляет смысл CSP. OWASP и web.dev рекомендуют стремиться к строгой политике на основе nonce или хешей, а не бесконечному списку доверенных хостов.

Проверяйте не только консоль, но и действия пользователя

Отсутствие заметных ошибок на первом экране ещё не означает, что политика готова. Пройдите ключевые сценарии на тестовом окружении и в Report-Only на рабочем сайте. Отправьте формы, откройте модальные окна, воспроизведите видео, пройдите оплату в тестовом режиме, проверьте события аналитики и загрузку страниц на мобильном устройстве.

Собирайте данные в течение репрезентативного периода: должны успеть сработать редкие шаблоны, рекламные посадочные и действия, которые выполняются не при каждом визите. Точную продолжительность выбирают по трафику и устройству сайта, а не по универсальному числу дней.

Переходите к блокировке постепенно

Когда источники классифицированы, лишние зависимости удалены, а важные сценарии проходят проверку, перенесите политику на тестовое окружение в режиме Content-Security-Policy. Сначала контролируйте небольшой набор шаблонов или трафика, если инфраструктура это позволяет.

После включения на рабочем сайте продолжайте принимать отчёты. Новая версия виджета, менеджера тегов или шаблона может добавить источник и снова нарушить политику. CSP — не разовая строка в конфигурации, а проверяемая часть выпуска изменений.

Чек-лист подготовки CSP

Выбраны ключевые страницы и пользовательские сценарии.
Собраны фактические источники скриптов, соединений, изображений, шрифтов и фреймов.
Найдены inline-обработчики, eval() и другие места, несовместимые со строгой политикой.
Настроен защищённый приёмник отчётов с ограничением объёма и частоты запросов.
Report-Only передаётся HTTP-заголовком и не блокирует рабочие ресурсы.
События разделены на нужные зависимости, устаревший код, клиентский шум и неизвестные источники.
Неизвестные домены проверены до добавления в разрешения.
Формы, оплата, аналитика, карты, видео и мобильные сценарии пройдены вручную.
Блокирующая политика сначала испытана на тестовом окружении.
После выпуска сохранены мониторинг отчётов и порядок отката.

Вопросы о CSP и проверке скриптов

Report-Only уже защищает сайт от вредоносного скрипта?

Нет. Этот режим фиксирует нарушения проектируемой политики, но не блокирует загрузку и выполнение ресурсов. Его задача — показать последствия будущих ограничений до перехода к Content-Security-Policy.

Можно ли просто разрешить все домены из отчётов?

Такой подход может узаконить ненужный или внедрённый источник. Сначала подтвердите назначение домена, найдите место подключения и решите, нужен ли ресурс. Для строгой защиты предпочтительнее nonce или хеши, а не широкий список хостов.

Что VOWE проверяет перед настройкой защиты сайта?

Состав зависит от CMS и хостинга. В рамках проверки безопасности сайта VOWE рассматриваются CMS, плагины и модули, права доступа, формы, настройки хостинга и подозрительные изменения. CSP имеет смысл настраивать вместе с этими проверками, а не вместо них.