Dlaczego tryb Report-Only różni się od trybu Enforced w Content Security Policy

By Mirko Peters · 2026-04-23

Jeśli poważnie traktujesz bezpieczeństwo aplikacji webowych, zrozumienie różnicy między trybami „report-only” a „enforced” w Content Security Policy (CSP) to nie drobny szczegół – to podstawa. Tryb report-only pozwala sprawdzić, co zostałoby zablokowane przez Twoją politykę, bez faktycznego blokowania czegokolwiek, dzięki czemu Twoja witryna staje się swego rodzaju poligonem do testów bezpieczeńst

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

Cover: Fix Conditional Access Loopholes in Microsoft 365

Ten artykuł wyjaśnia, dlaczego te tryby mają znaczenie, jaki mają wpływ na przeglądarkę i doświadczenie użytkownika oraz jak przejść od prostego monitorowania do realnej ochrony. Jest przeznaczony przede wszystkim dla specjalistów ds. bezpieczeństwa i deweloperów pracujących w środowisku Microsoft, którzy chcą poprawnie skonfigurować CSP. Omawiamy definicje, praktyczne techniki oraz najlepsze praktyki bezpiecznego wdrażania i inteligentnej zgodności z wymogami.

Zrozumienie trybów CSP i ich wpływu

Zanim zaczniesz dodawać nagłówki CSP, musisz poznać dwa główne tryby: report-only i enforced. Nie są to zwykłe ustawienia – decydują o tym, jak nowoczesne przeglądarki chronią (lub jedynie obserwują) granice bezpieczeństwa Twojej aplikacji webowej. Wybór trybu bezpośrednio wpływa na poziom ryzyka, zdolność do audytu i płynność wdrożenia, zwłaszcza w dużych środowiskach Microsoft lub konfiguracjach multi-cloud.

Tryby CSP zostały zaprojektowane z myślą o elastyczności zespołów webowych. Tryb report-only to łagodny punkt wejścia: pozwala monitorować problemy bez ryzyka, że przypadkiem coś zepsujesz dla użytkowników. Wspiera ocenę ryzyka, pomaga wykrywać luki w polityce oraz identyfikować starszy kod lub nieoczekiwane zachowania komponentów zewnętrznych, a jednocześnie aplikacja pozostaje w pełni sprawna.

Tryb enforced to główne wydarzenie: nakazuje przeglądarce faktycznie wykonać Twoje instrukcje. Jeśli treść nie spełnia wymagań polityki, zostaje zablokowana – co natychmiast ogranicza powierzchnię ataku na przykład w przypadku cross-site scripting czy złośliwych skryptów zewnętrznych. Oznacza to jednak także, że błędy lub niepełne zasady mogą przerwać działanie aplikacji, jeśli nie zadbasz o odpowiednie testy i stopniowe wdrażanie.

Idea posiadania obu trybów CSP jest prosta: pozwól deweloperom i zespołom bezpieczeństwa dopracować reguły w warunkach produkcyjnych, zanim włączysz pełne egzekwowanie. Potraktuj to jak kółka pomocnicze dla bezpieczeństwa aplikacji, z metą, na której przechodzisz do pełnego egzekwowania. W dalszej części wyjaśnimy, jak tryb report-only dostarcza realnej informacji zwrotnej i co zmienia się, gdy do gry wchodzi egzekwowanie.

Jak nagłówek Content-Security-Policy-Report-Only działa przy raportowaniu naruszeń

Tryb report-only to sposób CSP na obserwowanie z trybun, zanim wejdziesz na boisko. Gdy używasz nagłówka HTTP Content-Security-Policy-Report-Only, instruujesz przeglądarkę, by „sprawdzała naruszenia, ale niczego nie blokowała – tylko je zgłaszała”. Dzięki temu otrzymujesz strumień raportów o naruszeniach, dostarczanych do wskazanego punktu końcowego, i pełny obraz tego, co zostałoby zablokowane, gdyby polityka była egzekwowana.

Przeglądarki wysyłają te raporty o naruszeniach (często jako ładunki JSON) zawsze, gdy zasób narusza reguły CSP. Na przykład, jeśli strona próbuje załadować skrypt z niezatwierdzonego źródła, w trybie report-only żaden skrypt nie zostaje zablokowany – ale nadal otrzymasz alert oraz szczegóły, takie jak adres URL sprawcy, dyrektywa, która została naruszona, a czasem również fragment podejrzanego kodu.

Ten tryb jest bezcenny przy ocenie ryzyka i bezpiecznym testowaniu. Możesz wdrażać nowe reguły w wielu aplikacjach webowych, monitorować, co je uruchamia, i dostrajać politykę na podstawie rzeczywistych danych, a nie tylko domysłów. Jeśli utrzymujesz systemy legacy lub krytyczne procesy biznesowe, nie ryzykujesz przestojów ani lawiny zgłoszeń do wsparcia, idąc zbyt szybko.

Report-only wspiera także stopniowe wdrażanie. Zacznij od luźnych zasad, sprawdź, co wymaga korekty, i przechodź krok po kroku do coraz ściślejszych zabezpieczeń. Pozwala wykryć problemy z komponentami zewnętrznymi, zawartością CDN czy zaciemnionym JavaScriptem, które w przeciwnym razie ujawniłyby się dopiero wtedy, gdy egzekwowanie spowoduje spektakularną awarię. Dodatkowo to zwycięstwo w obszarze zgodności: masz dowód, że aktywnie monitorujesz środowisko, co pomaga podczas audytów, gdy organizacja musi wykazać należytą staranność.

Jak tryb enforced zwiększa bezpieczeństwo

Tryb wymuszony to moment, w którym zasady CSP przestają być sugestią i stają się regułą. Gdy używasz nagłówka Content-Security-Policy, przeglądarki faktycznie blokują każdą zawartość niezgodną z dyrektywami – bez ostrzeżeń, od razu podejmują działanie.

Ten tryb znacząco wzmacnia aplikację webową przed atakami takimi jak XSS czy nieautoryzowane wstrzykiwanie skryptów. Trzeba jednak uważać: jeśli zasady nie są gotowe do użycia produkcyjnego, możesz przypadkowo zablokować niezbędne zasoby i zepsuć działanie witryny. Mądrym krokiem jest najpierw przetestowanie w trybie tylko raportowania. Ostatecznie tryb wymuszony sprawia, że teoretyczne zasady stają się praktyczną ochroną, i dlatego uchodzi za złoty standard silnych zabezpieczeń webowych.

Implementacja raportowania z punktami końcowymi Report-URI i Report-To

Konfiguracja raportowania sprawia, że zasady CSP zyskują realną siłę – i dodatkowe oczy. CSP pozwala określić jeden lub więcej punktów końcowych (za pomocą report-uri lub report-to), na które przeglądarki mają wysyłać raporty o naruszeniach. Gdy dojdzie do naruszenia, przeglądarka pakuje szczegóły, takie jak zablokowany zasób i zasady, których nie spełniono, w komunikat JSON lub HTTP POST i wysyła go do Twojego punktu końcowego.

Dyrektywa report-uri to metoda starszego typu: podajesz adres URL, a przeglądarki wysyłają tam raporty bezpośrednio. Nowszym, bardziej elastycznym i bogatszym w informacje rozwiązaniem jest jednak report-to, zwłaszcza w miarę jak przeglądarki rozszerzają obsługę Reporting API. report-to działa z nazwaną grupą, która może obsługiwać różne typy raportów, i oferuje lepszą kontrolę filtrowania.

Konfigurując te punkty końcowe, warto je zabezpieczyć: stosować HTTPS, kontrolę dostępu i monitorowanie nietypowych skoków liczby raportów, które mogą wskazywać na atak lub błędnie działające zasady. Nie zapominaj też o prywatności: raporty mogą zawierać adresy URL, a nawet fragmenty niepożądanego skryptu, więc musisz być przygotowany na usuwanie wrażliwych informacji przed ich zapisaniem lub udostępnieniem, pamiętając o przepisach takich jak RODO i CCPA.

Prawdziwa siła tego rozwiązania tkwi w widoczności. Dzięki poprawnie skonfigurowanemu raportowaniu otrzymujesz na bieżąco informacje o tym, gdzie Twoje zasady wychwytują naruszenia, dzięki czemu możesz je dostosować, precyzyjnie ustawić i ostatecznie bezpiecznie przejść do egzekwowania bez niespodzianek. Taki poziom monitorowania jest niezbędny, niezależnie od tego, czy zarządzasz pojedynczą aplikacją, czy rozległym środowiskiem Microsoft 365.

Poruszanie się po składni i dyrektywach CSP w celu skutecznego projektowania zasad

Napisanie solidnego nagłówka CSP nie jest rocket science, ale wymaga dbałości o szczegóły – zwłaszcza gdy jednocześnie obsługujesz złożone aplikacje i integracje z chmurą Microsoft. Podstawą jest to, że zasady CSP to uporządkowana lista dyrektyw, z których każda określa, co przeglądarka może, a czego nie może zrobić. Przesyłasz te zasady w nagłówkach HTTP, zazwyczaj jako Content-Security-Policy lub Content-Security-Policy-Report-Only, zapisane w postaci ciągów reguł rozdzielonych średnikami.

Sednem zasad są kluczowe dyrektywy, takie jak default-src, script-src i img-src. default-src działa jako wartość zapasowa – jeśli dany typ zawartości nie ma własnej reguły, przeglądarka sprawdza właśnie tę. script-src i img-src koncentrują się odpowiednio na skryptach i obrazach, pozwalając ściśle kontrolować zaufane źródła (np. Twoje domeny, zaufane sieci CDN i być może jeden czy dwa kontenery blob w Microsoft Azure).

Składnia ma znaczenie. Każda dyrektywa zawiera listę dozwolonych wartości: adresy URL, schematy takie jak ‘https:’ lub słowa kluczowe, np. ‘self’. Jeśli dopuszczasz skrypty inline (czasem wymagane przez starszy kod), może być potrzebna wartość ‘unsafe-inline’, ale zachowaj ostrożność – osłabia ona ochronę, chyba że użyjesz skrótów (hashy) skryptów lub nonce’ów dla dodatkowej weryfikacji.

Jeśli pracujesz w środowisku firmowym, zwróć uwagę na to, jak usługi chmurowe wstrzykują zależności. Złożone aplikacje korporacyjne często ładują zasoby dynamicznie, korzystają z service workerów lub integrują zewnętrznych dostawców. Zasady muszą równoważyć restrykcyjność (ze względu na bezpieczeństwo) z elastycznością, która pozwoli aplikacji działać. Jeśli od początku dobrze opanujesz podstawy, testowanie pójdzie znacznie gładziej.

Najlepsze praktyki przejścia z trybu tylko raportowania do trybu wymuszonego

Najmądrzejszym posunięciem przy CSP jest rozpoczęcie od trybu tylko raportowania, zebranie danych, a dopiero potem włączenie egzekwowania. Nie traktuj wdrożenia CSP jak jednorazowej listy kontrolnej. Podchodź do tego jako do projektu etapowego, w którym monitorujesz, dopracowujesz i stopniowo wzmacniasz zasady, aby nie zakłócić działania dla użytkowników końcowych ani kluczowych procesów biznesowych.

Zacznij od wdrożenia szerokich, ale rozsądnych zasad w trybie tylko raportowania. Zbieraj raporty o naruszeniach. Najlepiej agreguj je w pulpitach nawigacyjnych lub narzędziach analitycznych, aby wyłapać powtarzających się sprawców. Pomaga to przebić się przez szum, odfiltrować fałszywe alarmy i skupić się na rzeczywistych zagrożeniach. Jeśli znajdziesz mnóstwo rutynowych lub nadmiarowych raportów (co jest typowe), dostosuj analizę logów albo utwórz skrypty filtrujące według agenta użytkownika lub typu zasobu.

Gdy liczba naruszeń spadnie i większość problemów zostanie rozwiązana, zacznij stopniowo wymuszać reguły, nadal monitorując pojawianie się nowych awarii. Najpierw przełącz w tryb wymuszania sekcje wysokiego ryzyka o niewielkim ruchu i obserwuj je. Jeśli wszystko przebiega gładko, rozszerz zmiany na resztę projektu. Dokumentuj zmiany i zbieraj opinie deweloperów oraz interesariuszy przez cały proces, zwłaszcza w złożonych aplikacjach Microsoft 365 lub Azure, gdzie warstwy warunkowego dostępu dodają kolejne komplikacje. Jeśli szukasz powiązanych strategii i planów wdrożenia, warto zajrzeć do tego przewodnika o problemach z zaufaniem w warunkowym dostępie oraz do tego odcinka o bezpieczeństwie tożsamości.

Nigdy nie lekceważ testów. Użyj narzędzi deweloperskich przeglądarki, testerów statusu CSP, a nawet zautomatyzowanych skanów w CI/CD, aby potwierdzić, że zasady działają zgodnie z oczekiwaniami. Cel końcowy? Zabezpieczona, zgodna z wymogami i odporna aplikacja, chroniona zasadą dopracowaną w warunkach rzeczywistych, a nie na podstawie życzeniowego myślenia.

Rzeczywiste przykłady CSP w trybie tylko raportowania i w trybie wymuszania

Nic nie ilustruje CSP lepiej niż konkretne przykłady. W trybie tylko raportowania możesz użyć nagłówka w rodzaju: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://csp-report.example.com. Taka konfiguracja rejestruje każde naruszenie, ale nie przeszkadza użytkownikom, dzięki czemu idealnie nadaje się do testowania na produkcji bez ryzyka.

Porównaj to z wymuszaną zasadą: Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src 'self'; report-uri https://csp-report.example.com. Teraz przeglądarka aktywnie blokuje każdy skrypt lub obraz niezgodny z regułami, chroniąc użytkowników przed niezatwierdzonymi treściami od razu.

W praktyce organizacje zaczynają od trybu tylko raportowania, aby ustalić, którzy dostawcy, skrypty lub funkcje biznesowe przestałyby działać przy ścisłej blokadzie. Na przykład portal internetowy administracji państwowej może odkryć przestarzałe skrypty lub sieć CDN do analityki marketingowej, która powoduje powtarzające się naruszenia. Zespół iteruje, dodaje bezpiecznych dostawców do listy dozwolonych, a następnie wymusza gotową zasadę etapami, aby zminimalizować zakłócenia.

Przejście z trybu tylko raportowania do wymuszania może ujawnić ukryte pułapki, zwłaszcza przy skryptach zewnętrznych lub treściach dynamicznych. Zespoły często napotykają „fantomowe” naruszenia, które pojawiają się tylko w określonych przeglądarkach lub w określonych warunkach. Korzystając z danych z fazy raportowania, dostosowują zasadę tak, aby wymuszanie było nie tylko bezpieczne, ale także stabilne dla wszystkich zaangażowanych.

Podsumowanie kluczowych różnic między trybem tylko raportowania a trybem wymuszania

Zachowanie: Tryb tylko raportowania jedynie zgłasza naruszenia zasad, nie blokując żadnych treści. Tryb wymuszania aktywnie blokuje wszystko, co narusza zasady CSP.
Cel: Tryb tylko raportowania pozwala testować i dostrajać zasady bez ryzyka dla użytkowników. Tryb wymuszania służy rzeczywistej ochronie i nadaje regułom bezpieczeństwa realne znaczenie.
Wpływ na użytkowników: Tryb tylko raportowania jest niewidoczny, użytkownicy nigdy go nie zauważają. Tryb wymuszania może zepsuć funkcje lub treści, jeśli reguły nie zostały wcześniej przetestowane.
Zastosowania: Tryb tylko raportowania idealnie nadaje się do stopniowych wdrożeń, analizy ryzyka i sprawdzania zgodności ze starszymi rozwiązaniami. Tryb wymuszania jest ostatnim krokiem do osiągnięcia solidnego, zgodnego z wymogami bezpieczeństwa.
Zgodność & ryzyko: Tryb tylko raportowania ułatwia monitorowanie i dokumentowanie podczas audytów, natomiast tryb wymuszania bezpośrednio zapobiega naruszeniom bezpieczeństwa w czasie rzeczywistym.