Dlaczego tryb report-only różni się od trybu enforced w Content Security Policy

By Mirko Peters · 2026-04-23

Jeśli poważnie podchodzisz do bezpieczeństwa stron internetowych, zrozumienie różnicy między trybami „report-only” a „enforced” w Content Security Policy (CSP) to nie jest drobny szczegół – to kluczowa sprawa. Tryb report-only pozwala zobaczyć, co zostałoby zablokowane przez Twoją politykę, bez faktycznego blokowania czegokolwiek, dzięki czemu Twoja strona staje się swego rodzaju poligonem do test

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, jak wpływają 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 rozsyłać nagłówki CSP, musisz opanować dwa główne tryby CSP: report-only i enforced. Nie są to zwykłe ustawienia – decydują o tym, jak nowoczesne przeglądarki chronią (albo jedynie obserwują) granice bezpieczeństwa Twojej aplikacji webowej. Wybór trybu bezpośrednio wpływa na poziom ryzyka, możliwości audytu i płynność wdrożenia, zwłaszcza w dużych środowiskach Microsoft lub konfiguracjach multi-cloud.

Tryby CSP zostały zaprojektowane tak, aby dać zespołom webowym elastyczność. Tryb report-only to łagodny punkt wejścia: pozwala monitorować problemy bez obawy, że przypadkiem zepsujesz coś użytkownikom. Wspiera ocenę ryzyka, pomaga wykrywać luki w polityce i może identyfikować stary kod lub nieoczekiwane zachowania komponentów zewnętrznych – a wszystko to przy pełnej sprawności aplikacji.

Tryb enforced to właściwy sprawdzian: nakazuje przeglądarce faktycznie wykonać Twoje instrukcje. Jeśli treść nie jest zgodna z polityką, zostaje zablokowana, co natychmiast ogranicza powierzchnię ataku w przypadku takich zagrożeń jak cross-site scripting czy złośliwe skrypty zewnętrzne. 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 wdrożenie.

Idea stojąca za istnieniem obu trybów CSP jest prosta: pozwól deweloperom i zespołom bezpieczeństwa dopracować reguły w realnym środowisku, zanim pociągniesz za spust. Traktuj to jak kółka pomocnicze dla bezpieczeństwa aplikacji, z metą, na której przechodzisz do pełnego egzekwowania. W następnej kolejności przyjrzymy się dokładnie, jak tryb report-only dostarcza tej informacji zwrotnej z rzeczywistego ruchu i co się zmienia, gdy do gry wchodzi egzekwowanie.

Jak działa Content-Security-Policy-Report-Only w 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 – jedynie je zgłaszała”. Dzięki temu otrzymujesz strumień raportów o naruszeniach dostarczanych do wskazanego punktu końcowego, czyli pełny przegląd tego, co zostałoby zablokowane, gdyby polityka działała w trybie egzekwowania.

Przeglądarki wysyłają te raporty o naruszeniach (najczęściej jako ładunki JSON) zawsze wtedy, gdy zasób narusza reguły CSP. Na przykład jeśli strona próbuje załadować skrypt z nieautoryzowanego źródła, w trybie report-only żaden skrypt nie zostaje zablokowany, ale otrzymasz alert oraz szczegóły, takie jak adres URL sprawcy, naruszona dyrektywa, a czasem także próbka 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 zaryzykujesz przestojów ani lawiny zgłoszeń do wsparcia, przechodząc zbyt szybko.

Report-only wspiera również stopniowe wdrażanie. Zacznij od luźnych ustawień, sprawdź, co wymaga korekty, i krok po kroku zmierzaj do ściślejszych zabezpieczeń. Pozwala zespołom wykryć problemy z komponentami zewnętrznymi, treścią z CDN czy zaciemnionym JavaScriptem, które w przeciwnym razie mogłyby ujawnić się dopiero wtedy, gdy egzekwowanie spowoduje spektakularną awarię. Do tego to wygrana w kwestii zgodności: masz dowód, że aktywnie monitorujesz środowisko, co może pomóc 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ą, a stają się regułą. Gdy używasz nagłówka Content-Security-Policy, przeglądarki faktycznie blokują każdą treść niezgodną z dyrektywami — bez ostrzeżeń, po prostu działają.

Ten tryb znacznie wzmacnia aplikację webową na ataki, takie jak XSS i nieautoryzowane wstrzykiwanie skryptów. Uważaj jednak: jeśli Twoje zasady nie są jeszcze gotowe do użycia produkcyjnego, możesz przypadkiem zablokować potrzebne zasoby i zepsuć działanie witryny. Mądrym posunięciem jest najpierw przetestować zasady 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.

Konfigurowanie raportowania za pomocą punktów końcowych Report-URI i Report-To

Konfigurowanie raportowania sprawia, że zasady CSP zyskują realne zęby — i parę oczu. CSP pozwala określić jeden lub więcej punktów końcowych (za pomocą report-uri lub report-to), do których 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 czytelną wiadomość JSON lub HTTP POST, a następnie wysyła ją do Twojego punktu końcowego.

Dyrektywa report-uri to metoda starszego typu: podajesz adres URL, a przeglądarki wysyłają tam raporty bezpośrednio. Nowszą, bardziej elastyczną i bogatszą w informacje opcją jest jednak report-to, szczególnie w miarę jak przeglądarki rozszerzają obsługę Reporting API. Report-to współpracuje z nazwaną grupą, która może obsługiwać różne typy raportów, i zapewnia lepszą kontrolę filtrowania.

Konfigurując te punkty końcowe, warto zadbać o ich zabezpieczenie: używać HTTPS, kontrolować dostęp i monitorować nietypowe skoki liczby raportów, które mogą wskazywać na atak lub uszkodzone zasady. Nie zapominaj też o prywatności: raporty mogą zawierać adresy URL, a nawet fragmenty problematycznego skryptu, dlatego przed ich zapisaniem lub udostępnieniem trzeba być gotowym do usunięcia informacji wrażliwych, z uwzględnieniem przepisów 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 wyregulować i bezpiecznie przejść do egzekwowania bez niespodzianek. Taki poziom monitoringu jest niezbędny, niezależnie od tego, czy zarządzasz pojedynczą aplikacją, czy rozległym środowiskiem Microsoft 365.

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

Napisanie solidnego nagłówka CSP nie jest rocket science, ale wymaga dbałości o szczegóły — szczególnie gdy jednocześnie obsługujesz złożone aplikacje i integracje z usługami chmurowymi Microsoft. U podstaw zasady CSP to uporządkowana lista dyrektyw, z których każda informuje przeglądarkę, co jest dozwolone, a co nie. Zasady przesyłasz w nagłówkach HTTP, zazwyczaj jako Content-Security-Policy lub Content-Security-Policy-Report-Only, w postaci ciągów reguł oddzielonych średnikami.

Sercem zasad są kluczowe dyrektywy, takie jak default-src, script-src i img-src. Dyrektywa default-src działa jako rezerwa — jeśli dany typ treści nie ma własnej reguły, przeglądarka sprawdza właśnie tę. Dyrektywy 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, a może też kontener Microsoft Azure Blob).

Składnia ma znaczenie. Każda dyrektywa zawiera listę dozwolonych wartości: adresy URL, schematy, takie jak ‘https:’, lub słowa kluczowe, takie jak ‘self’. Jeśli zezwalasz na skrypty inline (czasem wymagane przez starszy kod), może być potrzebna wartość ‘unsafe-inline’, ale uważaj — osłabia ona ochronę, chyba że zastosujesz hashe skryptów lub nonce dla dodatkowej weryfikacji.

Jeśli pracujesz z rozwiązaniami Microsoft, zwróć uwagę na to, jak usługi chmurowe wstrzykują zależności. Złożone aplikacje firmowe często dynamicznie ładują zasoby, korzystają z service workerów lub integrują dostawców zewnętrznych. Zasady muszą równoważyć rygor (ze względu na bezpieczeństwo) z elastycznością, która pozwoli aplikacji działać. Dobre opanowanie podstaw na początku sprawi, że późniejsze testy pójdą znacznie sprawniej.

Najlepsze praktyki przechodzenia od trybu tylko raportowania do trybu wymuszonego

Najrozsądniejszym podejściem do CSP jest rozpoczęcie od trybu tylko raportowania, zebranie danych, a dopiero potem włączenie egzekwowania. Nie traktuj wdrożenia CSP jak listy kontrolnej do odhaczenia raz i na zawsze. Zamiast tego podchodź do niego jak do projektu fazowego, w którym monitorujesz, dostrajasz i stopniowo wzmacniasz zasady, aby nie zakłócać działania aplikacji dla użytkowników końcowych ani krytycznych procesów biznesowych.

Zacznij od wdrożenia szerokich, ale rozsądnych zasad w trybie samego raportowania. Zbieraj raporty o naruszeniach. Najlepiej agreguj je w panelach lub narzędziach analitycznych, aby wyłapać powtarzających się sprawców. Pozwoli to przebić się przez szum, odfiltrować fałszywe alarmy i skupić się na rzeczywistych zagrożeniach. Jeśli napotkasz mnóstwo rutynowych lub zbędnych raportów (a to typowe), dostrój analizę logów lub utwórz skrypty filtrujące według agenta użytkownika bądź typu zasobu.

Gdy liczba naruszeń spadnie, a większość problemów zostanie usunięta, zacznij stopniowo egzekwować reguły, nadal monitorując pojawiające się nowe awarie. Najpierw przełącz w tryb egzekwowania sekcje wysokiego ryzyka i o niewielkim ruchu, a potem monitoruj je. Jeśli wszystko przebiega bez zakłóceń, rozszerz zmiany na resztę projektu. Dokumentuj zmiany i zbieraj opinie deweloperów oraz interesariuszy na każdym etapie, zwłaszcza w złożonych aplikacjach Microsoft 365 lub Azure, gdzie warstwy dostępu warunkowego dodają kolejne komplikacje. Informacje o powiązanych strategiach i planach wdrożenia warto znaleźć w tym przewodniku o problemach z zaufaniem w dostępie warunkowym oraz w tym odcinku o bezpieczeństwie tożsamości.

Nigdy nie lekceważ testów. Używaj narzędzi deweloperskich przeglądarki, testerów statusu CSP, a nawet zautomatyzowanych skanów CI/CD, aby potwierdzić, że zasady działają zgodnie z oczekiwaniami. Cel końcowy? Zabezpieczona, zgodna z wymogami i odporna aplikacja, chroniona zasadami, które zostały wypracowane w praktyce, a nie oparte na życzeniowym myśleniu.

Przykłady z praktyki: CSP w trybach raportowania i egzekwowania

Nic nie ożywia CSP tak jak prawdziwe przykłady. W trybie 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 zakłóca pracy użytkowników, dlatego idealnie nadaje się do testów na środowisku produkcyjnym bez ryzyka.

Dla porównania, zasada w trybie egzekwowania: Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src 'self'; report-uri https://csp-report.example.com. Przeglądarka aktywnie blokuje każdy skrypt lub obraz, który nie spełnia reguł, i od razu chroni użytkowników przed nieautoryzowaną treścią.

W praktyce organizacje zaczynają od trybu raportowania, aby wykryć, którzy dostawcy, skrypty lub funkcje biznesowe przestałyby działać przy takiej blokadzie. Na przykład portal internetowy administracji państwowej może odkryć przestarzałe skrypty albo sieć CDN do analityki marketingowej, która wielokrotnie generuje naruszenia. Zespół iteruje, dodaje bezpiecznych dostawców do białej listy, a następnie stopniowo egzekwuje gotową zasadę, aby ograniczyć zakłócenia.

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

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

Działanie: Tryb raportowania jedynie zgłasza naruszenia zasad, a żadna treść nie zostaje zablokowana. Tryb egzekwowania aktywnie blokuje wszystko, co narusza Twoją zasadę CSP.
Cel: Tryb raportowania pozwala testować i dostrajać zasady bez ryzyka dla użytkowników. Tryb egzekwowania służy faktycznej ochronie i sprawia, że reguły bezpieczeństwa zaczynają realnie obowiązywać.
Wpływ na użytkowników: Tryb raportowania jest niewidoczny, użytkownicy nigdy go nie zauważają. Tryb egzekwowania może zepsuć funkcje lub treści, jeśli reguły nie zostały wcześniej przetestowane.
Zastosowania: Tryb raportowania idealnie sprawdza się przy stopniowych wdrożeniach, analizie ryzyka i testowaniu zgodności ze starszymi rozwiązaniami. Tryb egzekwowania to ostatni krok do uzyskania solidnego, zgodnego z wymogami zabezpieczenia.
Zgodność i ryzyko: Tryb raportowania wspiera monitorowanie i dokumentowanie na potrzeby audytów, natomiast tryb egzekwowania bezpośrednio zapobiega naruszeniom bezpieczeństwa w czasie rzeczywistym.