Почему режимы Report-Only и Enforced в Content Security Policy работают по-разному

By Mirko Peters · 2026-04-23

Если вы серьёзно относитесь к веб-безопасности, разница между режимами «report-only» и «enforced» в Content Security Policy (CSP) — это не мелочь, а суть дела. Режим report-only позволяет увидеть, что было бы заблокировано вашей политикой, ничего при этом не останавливая, и превращает ваш сайт в своего рода полигон для тестирования безопасности. Режим enforced, напротив, не шутит: он блокирует всё

Automatically translated with AI from the original post. Read the English original

Cover: Fix Conditional Access Loopholes in Microsoft 365

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

Понимание режимов CSP и их влияния

Прежде чем начать добавлять заголовки CSP, нужно разобраться в двух основных режимах: report-only и enforced. Это не просто настройки: от выбранного режима зависит, как современные браузеры защищают границы безопасности вашего веб-приложения (или только наблюдают за ними). Выбор напрямую влияет на уровень риска, возможности аудита и на то, насколько гладко пройдёт внедрение, особенно в крупных средах Microsoft или в мультиоблачных конфигурациях.

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

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

Идея наличия обоих режимов CSP проста: дать разработчикам и специалистам по безопасности возможность доработать правила в реальных условиях, прежде чем включать жёсткое применение. Это похоже на стабilizers для безопасности приложения, только с финишной чертой, после которой вы переходите к полному enforcement. Далее мы подробно разберём, как report-only даёт обратную связь из реального мира и что меняется, когда в игру вступает enforcement.

Как Content-Security-Policy-Report-Only работает для отчётов о нарушениях

Режим report-only — это способ CSP наблюдать с трибуны, прежде чем выйти на площадку. Когда вы используете HTTP-заголовок Content-Security-Policy-Report-Only, вы указываете браузеру «следить за нарушениями, но ничего не блокировать, а только сообщать о них». Так вы получаете поток отчётов о нарушениях, которые отправляются на указанную вами конечную точку, и полную картину того, что было бы заблокировано, если бы политика применялась.

Браузеры отправляют эти отчёты о нарушениях (часто в виде JSON), когда ресурс нарушает правила CSP. Например, если страница пытается загрузить скрипт из неразрешённого источника, в режиме report-only скрипт не блокируется, но вы всё равно получите уведомление с подробностями: URL-адресом нарушителя, нарушенной директивой и иногда фрагментом подозрительного кода.

Этот режим бесценен для оценки рисков и безопасного тестирования. Вы можете развернуть новые правила для набора веб-приложений, отслеживать, что срабатывает, и настраивать политику на основе реальных данных, а не только предположений. Если вы работаете с устаревшими системами или с критически важными бизнес-процессами, вы не рискнёте простоем сайта и обращениями в поддержку, если не будете торопиться.

Report-only также поддерживает постепенное внедрение. Начните с открытой политики, посмотрите, что нужно скорректировать, и двигайтесь шаг за шагом к более строгой защите. Режим помогает выявить проблемы со сторонними скриптами, контентом CDN или запутанным JavaScript, которые иначе могли бы проявиться лишь тогда, когда enforcement вызовет серьёзный сбой. К тому же это плюс для соответствия требованиям: у вас есть подтверждение того, что вы активно ведёте мониторинг, что поможет при аудитах, когда организации нужно показать должную осмотрительность.

Как режим Enforced повышает безопасность

Enforced mode — это режим, в котором политика CSP перестаёт быть рекомендацией и становится правилом. Если вы используете заголовок Content-Security-Policy, браузеры действительно блокируют любой контент, который не соответствует вашим директивам: никаких предупреждений, только действие.

Этот режим существенно укрепляет защиту веб-приложения от атак вроде XSS и внедрения несанкционированных скриптов. Но будьте осторожны: если ваша политика ещё не готова к боевой эксплуатации, вы можете случайно заблокировать нужные ресурсы и нарушить работу сайта. Разумный шаг — сначала протестировать политику в режиме только отчётов. В итоге enforced mode превращает теоретическую политику в практическую защиту и становится золотым стандартом надёжной веб-безопасности.

Настройка отчётности через эндпоинты report-uri и report-to

Настройка отчётности — это момент, когда ваша политика CSP получает реальные зубы и «глаза». CSP позволяет указать один или несколько эндпоинтов (с помощью report-uri или report-to), на которые браузеры должны отправлять отчёты о нарушениях. При нарушении браузер упаковывает детали — какой ресурс был заблокирован и какая часть политики не сработала — в аккуратное сообщение в формате JSON или HTTP POST и отправляет его на ваш эндпоинт.

Директива report-uri — это устаревший способ: вы задаёте URL, и браузеры отправляют отчёты прямо туда. Однако для современной гибкости и более богатой отчётности новее и надёжнее report-to, особенно по мере расширения поддержки Reporting API в браузерах. report-to работает с именованной группой, которая может обрабатывать разные типы отчётов, и даёт более точный контроль фильтрации.

При настройке этих эндпоинтов их нужно защитить: используйте HTTPS, ограничивайте доступ и отслеживайте неожиданные всплески количества отчётов, которые могут указывать на атаку или неработающую политику. И не забывайте о приватности: отчёты могут содержать URL и даже фрагменты подозрительного скрипта, поэтому перед сохранением или передачей их нужно очищать от конфиденциальных данных с учётом требований таких регуляций, как GDPR и CCPA.

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

Навигация по синтаксису CSP и директивам для эффективного проектирования политики

Написать надёжный заголовок CSP не так уж сложно, но это требует внимания к деталям, особенно когда приходится учитывать сложные приложения и интеграции с облачными сервисами Microsoft. По сути, политика CSP — это структурированный список директив, каждая из которых сообщает браузеру, что разрешено, а что нет. Эти политики передаются в HTTP-заголовках, обычно как Content-Security-Policy или Content-Security-Policy-Report-Only, и записываются в виде строки правил, разделённых точками с запятой.

Основу политики составляют ключевые директивы: default-src, script-src и img-src. default-src — это значение по умолчанию: если для определённого типа контента нет собственного правила, браузер проверяет именно её. script-src и img-src отвечают за скрипты и изображения и позволяют жёстко контролировать доверенные источники (например, ваши домены, доверенные CDN и, возможно, пару хранилищ Blob в Azure).

Синтаксис имеет значение. Каждая директива перечисляет допустимые значения: URL, схемы вроде ‘https:’ или ключевые слова вроде ‘self’. Если вы разрешаете встроенные скрипты (иногда это требуется для устаревшего кода), может понадобиться ‘unsafe-inline’, но будьте осторожны: это ослабляет защиту, если не использовать хэши скриптов или nonce для дополнительной проверки.

Специалистам по Microsoft стоит обращать внимание на то, как облачные сервисы подгружают зависимости. Сложные корпоративные приложения часто загружают ресурсы динамически, используют service workers или интегрируют сторонних провайдеров. Политика должна balance между строгостью (ради безопасности) и гибкостью, чтобы приложение работало. Если правильно разобраться с основами заранее, тестирование потом пойдёт гораздо легче.

Лучшие практики перехода от режима только отчётов к enforced mode

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

Начните с широкой, но разумной политики в режиме только отчётов. Собирайте отчёты о нарушениях — желательно агрегируйте их с помощью дашбордов или инструментов аналитики, чтобы выделить повторяющихся нарушителей. Так проще отсечь шум, отфильтровать ложные срабатывания и сосредоточиться на реальных рисках. Если отчётов много и большинство из них рутинные или избыточные (что типично), настройте аналитику логов или даже напишите скрипты фильтрации по user agent или типу ресурса.

Когда объём нарушений снизится и большинство проблем будет устранено, начинайте постепенно включать правила в режим принудительного применения, продолжая отслеживать новые сбои. Сначала переведите в режим принудительного применения участки с высоким риском и низким трафиком и понаблюдайте за ними. Если всё проходит гладко, распространите политику на остальную часть проекта. Документируйте изменения и получайте обратную связь от разработчиков и заинтересованных сторон на всех этапах, особенно в сложных приложениях Microsoft 365 или Azure, где дополнительные сложности вносят слои условного доступа. Для смежных стратегий и планов развертывания стоит ознакомиться с этим руководством о проблемах доверия в условном доступе и этим выпуском о безопасности удостоверений.

Никогда не недооценивайте тестирование. Используйте инструменты разработчика в браузере, средства проверки статуса CSP и даже автоматизированные проверки в CI/CD, чтобы убедиться, что политики работают как ожидается. Конечная цель? Защищённое, соответствующее требованиям и устойчивое приложение, которое охраняется политикой, проверенной в реальных условиях, а не на основе благих пожеланий.

Практические примеры CSP в режимах «только отчёты» и принудительного применения

Ничто не иллюстрирует CSP лучше, чем реальные примеры. В режиме только отчётов можно использовать заголовок вида: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://csp-report.example.com. Такая настройка фиксирует каждое нарушение, но не затрагивает пользователей, что делает её идеальной для тестирования в продуктивной среде без риска.

В отличие от этого, принудительная политика выглядит так: Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src 'self'; report-uri https://csp-report.example.com. Теперь браузер активно блокирует любой скрипт или изображение, которые не соответствуют правилам, немедленно защищая пользователей от неодобренного контента.

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

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

Краткое сравнение режимов «только отчёты» и принудительного применения

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