После настройки безопасности сайт может выглядеть исправным, пока посетитель не откроет чат, не отправит форму или не перейдёт к оплате. Одной из причин может оказаться Content Security Policy: браузер запрещает ресурс, который нужен этому действию. В Гуси-Лебеди объясним, как устроена CSP, что проверять перед включением ограничений и как обсуждать результат с разработчиком.
CSP, или политика безопасности содержимого, задаёт правила для браузера. Сайт сообщает, какие источники ресурсов и действия разрешены. Это помогает уменьшить риск некоторых атак, включая выполнение внедрённого JavaScript. Но заголовок с названием CSP не гарантирует безопасность: важны сами правила и их применение. Политика дополняет безопасную разработку, а не заменяет исправление уязвимостей.
Что проверить на сайте перед настройкой CSP
Начните с пользовательских действий, а не с чужой строки конфигурации. У условного магазина на странице товара есть фотографии, скрипт корзины, счётчик аналитики и встроенный виджет доставки. Ресурсы могут приходить с разных адресов, а сетевые запросы появляться только после нажатия кнопки. Если проверить одну загрузку главной страницы, часть зависимостей останется незамеченной.
Составьте карту: какая функция использует ресурс, откуда он загружается, кто его подключил и нужен ли он сейчас. Например, отправка формы может зависеть от собственного JavaScript, внешнего CAPTCHA и отдельного адреса API. Разрешение загрузить скрипт не означает, что ему разрешено отправить запрос на любой адрес.
Мы советуем пройти каталог, поиск, форму, личный кабинет и другие важные сценарии на тестовом окружении. Для оплаты достаточно предусмотренного разработчиком тестового режима платёжного сервиса. Проверка CSP не требует реального списания денег. Отдельно посмотрите состояния ошибки и повторную попытку: они могут подключать дополнительные ресурсы.
Выясните, где формируется HTTP-ответ. Заголовок может добавляться приложением, веб-сервером или промежуточным сервисом. Если правил несколько, нельзя считать последнее объявление заменой всех предыдущих: действующие политики применяются совместно. Дублирование и их взаимодействие описаны в спецификации CSP. Перед изменением сохраните текущую конфигурацию и согласуйте способ восстановления.
Как читать директивы, self, nonce и hash
Политика состоит из директив, разделённых точками с запятой. Например, script-src управляет источниками JavaScript, style-src стилями, img-src изображениями, connect-src сетевыми соединениями соответствующих типов. default-src служит резервом для директив загрузки ресурсов, если более конкретное правило не указано. Это не универсальный запрет для любой возможности браузера. Обзор устройства политики есть в документации MDN.
Значение 'self' относится к тому же источнику, что и документ: учитываются схема, хост и порт. Не считайте автоматически разрешёнными все поддомены компании. Для CDN, внешнего API и другого поддомена нужно определить подходящее правило отдельно.
Две похожие директивы решают противоположные по направлению задачи. frame-src определяет, какие фреймы может загрузить страница. frame-ancestors определяет, кто может встроить саму страницу. Для последней нет резервного значения из default-src, и она не действует через CSP в meta. Поэтому заменить её настройкой frame-src или общей строкой default-src 'none' нельзя.
Вот учебный фрагмент для обсуждения на тестовом окружении, не готовая конфигурация для вашего сайта:
Content-Security-Policy-Report-Only:
default-src 'self';
script-src 'self';
object-src 'none';
base-uri 'self';
frame-ancestors 'self'Здесь указан режим наблюдения. Строка ограничивает ряд источников в проверяемой политике, но сама не блокирует их. Встроенные скрипты, сторонние виджеты и другие зависимости потребуют отдельного решения. Фрагмент также не настраивает приём отчётов: это самостоятельная часть внедрения.
Для разрешения определённого встроенного скрипта используют nonce или hash. Nonce представляет собой криптографически случайное значение, новое для каждого HTTP-запроса; оно должно совпасть в политике и атрибуте разрешённого скрипта. Постоянная строка «nonce123» эту задачу не решает. Hash привязан к содержимому скрипта: изменение текста, включая значимые для вычисления пробелы, требует обновления значения. Особенности этих способов разобраны в справке script-src.
Список доверенных доменов и разрешение конкретного скрипта не равнозначны. Доменное разрешение шире. Не добавляйте 'unsafe-inline' или 'unsafe-eval' просто ради исчезновения сообщения в консоли. Сначала выясните, какой код требует разрешения и можно ли изменить его подключение или реализацию. Для встроенных обработчиков событий действуют свои условия, их нельзя автоматически считать разрешёнными тем же nonce.
Report-Only: как разобрать нарушения до блокировки
Content-Security-Policy-Report-Only позволяет проверять предполагаемые ограничения без их применения как блокирующей политики. При этом уже существующая обычная CSP продолжает действовать. Такой режим передаётся HTTP-заголовком, а не элементом meta. Эти особенности подтверждены в документации Report-Only.
Для централизованного сбора сообщений нужно настроить получателя отчётов. В современном подходе адрес описывается через Reporting-Endpoints, а имя получателя указывается директивой report-to. Директива report-uri устарела, но вопрос совместимости решают с учётом поддержки браузеров. Детали приведены в справке по report-to. Просто вписанный адрес не подтверждает, что сообщения принимаются и сохраняются.
Разбирайте нарушение вместе со сценарием. В условном магазине чат открывается только после клика, затем обращается к отдельному API. Сообщение о connect-src в этот момент может указывать на неучтённую зависимость. Сначала воспроизведите действие и проверьте адрес. Если это ожидаемый запрос, решите, какое точное разрешение необходимо. Если адрес неизвестен, выясните происхождение подключения.
Не всякий отчёт доказывает атаку. Среди причин могут быть ошибка подключения, устаревший код, изменение внешнего сервиса или влияние расширения браузера. Это варианты для диагностики, а не диагноз по одному сообщению. Сохраните страницу, время, директиву и действие, при котором возникло нарушение. Повторите сценарий в предусмотренной тестовой среде и сравните результаты.
Отсутствие сообщений тоже не доказывает, что всё проверено. Возможно, нужный сценарий не выполнялся или сбор отчётов не работает. Для приёмки попросите показать и успешное получение тестового сообщения, и прохождение важных действий пользователя. Не назначайте одинаковый срок наблюдения всем сайтам: сначала определите, какие сценарии и варианты необходимо охватить.
Когда включать ограничения и как принять работу
Переходить к блокирующей политике разумно после разбора ожидаемых зависимостей и проверки функций. Само переключение заголовка не является приёмкой. Политика должна приходить в фактическом ответе нужных страниц, а формы, корзина и интеграции должны работать с ней. Проверяйте поведение после обычной загрузки, переходов внутри приложения и действий, которые подключают ресурсы позже.
- Конфигурация понятна. Для разрешённых источников есть назначение, а лишние подключения разобраны.
- Код согласован с политикой. Генерация nonce или обновление hash включены в работу приложения и сборку, если используются эти механизмы.
- Важные сценарии проходят. Проверены результат отправки формы, работа корзины и согласованные интеграции, а не только внешний вид страницы.
- Нарушения видны ответственному. Приём отчётов проверен; понятен порядок разбора новых сообщений.
- Изменения сопровождаются проверкой. Новый виджет, CDN или обновление приложения не добавляются без повторной оценки зависимостей.
Бесплатный анализатор политики может помочь найти очевидные слабые места, но не заменяет проверку приложения. Он не знает, дошла ли заявка до получателя и корректно ли работает ваш сценарий покупки. Эти критерии нужно определить отдельно.
При сопровождении и проверке безопасности сайта мы рекомендуем хранить карту зависимостей, правила CSP и сценарии приёмки вместе. Тогда обсуждение сводится к конкретному ресурсу и функции, а не к требованию «разрешить всё, чтобы заработало». Уточняйте совместимость по текущей документации и проверяйте изменения на своём приложении.