Краткий ответ

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

Чтобы браузер применял ограничения, нужен заголовок Content-Security-Policy без суффикса -Report-Only. Тестировщик должен проверить фактическое поведение браузера, а не только наличие похожего заголовка.

Исторический контекст

Content Security Policy (CSP) появилась как дополнительный браузерный слой защиты от последствий внедрения скриптов и загрузки ресурсов из недоверенных источников. Исходная проблема заключалась в том, что одной ошибки в обработке пользовательских данных могло быть достаточно для выполнения вредоносного JavaScript в контексте приложения.

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

Постановка проблемы

Если приложение использует только Content-Security-Policy-Report-Only, браузер может выполнить встроенный или загруженный скрипт, нарушающий указанное правило. Отчёт о нарушении не отменяет действие скрипта и не заменяет исправление уязвимости.

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

Подробное решение

Рабочая политика передаётся, например, так:

Content-Security-Policy: default-src 'self'; script-src 'self'

Браузер интерпретирует директивы и блокирует ресурсы, не соответствующие им. В режиме Report-Only те же нарушения регистрируются, но запрет не применяется.

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

CSP является защитой в глубину, а не заменой контекстному экранированию, безопасной обработке HTML и проверке входных данных. Слабая политика с 'unsafe-inline', 'unsafe-eval', чрезмерно широкими источниками или разрешением недоверенных доменов существенно снижает защитный эффект.

Ситуация из практики

В приложении обнаружили отражённое XSS, а сервер уже отправлял Content-Security-Policy-Report-Only. Рассматривались три варианта: оставить режим отчётности, немедленно включить строгую политику или сначала исправить XSS и затем поэтапно перейти к блокирующей политике.

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

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

Что кандидаты часто упускают

Вопрос: Может ли рабочая CSP полностью заменить контекстное экранирование?

Ответ: Нет. CSP снижает последствия некоторых атак, но не устраняет ошибку формирования HTML, атрибутов или JavaScript-кода. Политика может быть неполной, поддерживаться не всеми клиентами или содержать разрешения, позволяющие обойти ожидаемый барьер; первичной защитой остаётся корректная обработка данных в контексте вывода.
Вопрос: Почему наличие script-src 'self' не означает, что разрешены только безопасные скрипты?

Ответ: Директива разрешает скрипты с того же источника, включая потенциально опасные файлы, если злоумышленник способен разместить или подменить JavaScript на этом источнике. Кроме того, безопасность зависит от остальных директив, способа подключения скриптов и настроек вроде 'unsafe-inline'. Поэтому нужно оценивать, какие реальные ресурсы доступны с разрешённых источников, а не только читать название директивы.
Вопрос: Как отличить эффективно применяемую CSP от заголовка, который лишь присутствует в ответе?

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