Чому режим 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 проста: дати розробникам і командам безпеки відточити правила в реальних умовах, перш ніж натискати на «пуск». Уявіть це як навчальні колеса для безпеки вашого застосунку, але з фінішною лінією, після якої ви переходите до повноцінного примусового застосування. Далі ми детально розглянемо, як 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 і несанкціонованого впровадження скриптів. Але будьте обережні: якщо політика ще не готова до продакшена, ви можете випадково заблокувати потрібні ресурси й зламати роботу сайту. Розумний перший крок — тестування в режимі лише звітування (report-only). Зрештою, саме режим примусового застосування перетворює теоретичну політику на практичний захист і є золотим стандартом надійної веб-безпеки.

Налаштування звітності через кінцеві точки 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 і, можливо, пару контейнерів Azure Blob).

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

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

Найкращі практики переходу від режиму report-only до примусового застосування

Найрозумніший підхід до CSP — почати в режимі report-only, зібрати дані і лише потім увімкнути примусове застосування. Не сприймайте впровадження 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 для маркетингової аналітики, що постійно спричиняють порушення. Вони ітераційно додають безпечних постачальників до списку дозволених, а потім поетапно вводять готову політику в дію, щоб мінімізувати збої.

Перехід від режиму лише звітування до примусового може виявити приховані пastки, особливо зі сторонніми скриптами чи динамічним контентом. Команди часто стикаються з «примарними» порушеннями, які з'являються лише в окремих браузерах або за певних умов. Використовуючи живі дані з етапу звітування, вони коригують політику доти, доки примусове застосування не стане не лише безпечним, а й стабільним для всіх учасників.

Підсумок ключових відмінностей між режимами лише звітування та примусовим

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