Чому режими 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 жоден скрипт не блокується, але ви все одно отримаєте сповіщення з деталями: адресою ресурсу, порушеною директивою а іноді і фрагментом підозрілого коду.

Цей режим безцінний для оцінки ризиків і безпечного тестування. Ви можете розгорнути нові правила для цілого парку вебзастосунків, відстежувати, що спрацьовує, і коригувати політику на основі реальних даних, а не лише припущень. Якщо ви працюєте з застарілими системами або маєте критично важливі бізнес-процеси, ви не ризикуватимете простоями сайту чи зверненнями до підтримки через надто швидкі зміни.

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 і, можливо, один-два контейнери Azure Blob).

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

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

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

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

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

Головні відмінності між режимами лише звітування та примусового застосування

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