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

By Mirko Peters · 2026-04-23

Если вы всерьёз занимаетесь веб-безопасностью, разница между режимами «report-only» и «enforced» в Content Security Policy…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка отчётности с помощью конечных точек 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 в Microsoft Azure).

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

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

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

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

Начните с широкой, но разумной политики в режиме только отчётов. Собирайте отчёты о нарушениях — желательно агрегируйте их с помощью панелей мониторинга или инструментов аналитики, чтобы выявить повторяющихся нарушителей. Так проще отсеять шум, отфильтровать ложные срабатывания и сосредоточиться на реальных рисках. Если отчётов много и большая часть из них рутинные или избыточные (что típично), настройте аналитику логов или даже напишите скрипты фильтрации по 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 для маркетинговой аналитики, которые постоянно вызывают нарушения. Команда итеративно добавляет проверенных поставщиков в список разрешённых, а затем поэтапно включает готовую политику, чтобы минимизировать сбои.

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

Сводка ключевых различий между режимами только отчётов и принудительного применения

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