Content Security Policy (CSP) to standard bezpieczeństwa aplikacji webowych i stron internetowych. Funkcjonuje jako deklaratywna polityka określająca zasady dotyczące wykorzystywania zasobów powiązanych z dokumentem HTML. Obejmuje m.in.:

 

• skrypty,
• style CSS,
• obrazy,
• fonty,
• multimedia,
• komponenty osadzone.

 

CSP jest formalnym zestawem reguł bezpieczeństwa interpretowanych przez przeglądarkę. Reguły te są definiowane przez właściciela serwisu lub aplikacji.

 

Wersja 1.0 została opublikowana przez W3C ze statusem kandydata na rekomendację w 2012 roku. CSP Level 2 pojawił się jako rekomendacja W3C w 2016 roku i rozszerzył standard m.in. o mechanizmy nonce oraz hash. Obecnie rozwijana jest wersja CSP Level 3, która wprowadza większą granularność polityk i lepiej odpowiada na potrzeby nowoczesnych aplikacji webowych.

 

Jak podaje portal Can I use, w marcu 2026 roku standard CSP 1.0 był wspierany przez 97,02% używanych przeglądarek, a CSP Level 2 przez 96,71%.

 

Jak działa CSP? Mechanizm blokowania niechcianych skryptów.

 

W praktyce CSP pozwala zdefiniować tzw. whitelist, czyli listę zaufanych źródeł, z których strona może ładować skrypty i inne zasoby. Przeglądarka nie analizuje więc samego kodu, a jedynie sprawdza, czy dany zasób pasuje do reguł zapisanych w polityce.

 

Mechanizm działania Content Security Policy wygląda tak:

 

1. Serwer wysyła politykę CSP w nagłówku HTTP lub w metadanych dokumentu.

 

2. Przeglądarka odczytuje dyrektywy i ustala, jakie źródła są dozwolone dla skryptów.

 

3. Strona próbuje załadować skrypt.

 

4. Przeglądarka porównuje źródło z polityką i sprawdza, czy mieści się ono w dozwolonym zakresie.

 

5. Zgodny skrypt zostaje uruchomiony, a niezgodny zablokowany.

 

6. W przypadku naruszenia informacja o nim zostanie zapisana w konsoli lub wysłana do systemu raportowania.

 

Próbę wstrzyknięcia skryptu z niedozwolonego źródła, np. w formularzu, hamuje CSP, uniemożliwiając tym samym atak.

   

CSP chroni przed konkretnymi klasami zagrożeń:

 

• Cross-Site Scripting (XSS) – blokuje wykonanie wstrzykniętego kodu z nieautoryzowanych źródeł.
• Data injection – ogranicza możliwość wprowadzenia i wykonania niepożądanego kodu lub treści.
• Clickjacking – kontroluje osadzanie strony w iframe przez inne domeny.
• Złośliwe skrypty third-party – zapobiega ładowaniu niezaufanych bibliotek i zasobów zewnętrznych.
• Nieautoryzowane połączenia sieciowe – ogranicza możliwość wysyłania danych do obcych punktów końcowych.
• Modyfikacja DOM (Document Object Model, obiektowy model dokumentu, czyli struktura reprezentacji strony w pamięci przeglądarki) przez nieznane źródła – redukuje ryzyko manipulacji strukturą strony przez zewnętrzny kod.

 

Ataki XSS mieszczą się w kategorii Injection, która zajmuje 5. miejsce na liścieie OWASP Top 10:2025. Są one powiązane z ponad 30 tys. CVE w tej kategorii.

   

Według badania Web Almanac w 2025 roku nagłówek Content-Security-Policy miało 21,9% stron. To o 3,4 pp. więcej niż rok wcześniej. Znaczenie ma jednak nie tylko sama obecność CSP, ale też jakość konfiguracji. Zbyt restrykcyjna polityka może bowiem przerwać działanie aplikacji, z kolei zbyt liberalna nie wnosi realnej wartości do cyberbezpieczeństwa organizacji.

 

Dobre praktyki wdrożenia CSP obejmują:

 

• tryb raportowania (Report-Only) – zapewnia wdrożenie bez ryzyka zablokowania aplikacji lub strony, pozwala zbierać dane o naruszeniach bez wpływu na użytkowników,
• stopniowe zaostrzanie polityki – iteracyjne ograniczanie źródeł zamiast jednorazowego wprowadzenia restrykcji,
• inwentaryzacja zasobów – identyfikacja wszystkich skryptów objętych polityką CSP,
• unikanie unsafe-inline i unsafe-eval – eliminacja szerokich wyjątków, które osłabiają skuteczność CSP. Unsafe-inline to wartość zezwalająca na skrypty wpisane bezpośrednio w kodzie HTML, np. wewnątrz znaczników. Z kolei unsafe-eval to wartość pozwalająca na wykonywanie kodu ze stringów, np. przez funkcję eval,
• wykorzystanie nonce i hash – kontrola wykonania kodu inline bez otwierania całej polityki bezpieczeństwa CSP. Nonce to unikalny, jednorazowy token liczbowy, który dodaje się do bezpiecznych skryptów. Hash to kryptograficzny skrót konkretnego bloku kodu,
• monitoring naruszeń – analiza raportów CSP i logów przeglądarki w celu wykrywania błędów konfiguracji.

 

Dane Web Almanac wskazują, że w 2025 roku 92% polityk zawierało unsafe-inline, 77% unsafe-eval, natomiast nonce było używane zaledwie w około 20%.

       

Bezpieczeństwo aplikacji nie kończy się na konfiguracji CSP. Istotną rolę w jego zapewnieniu odgrywa sprawdzony partner telekomunikacyjny, który dostarcza infrastrukturę, monitoring i mechanizmy ochrony na poziomie sieci i ruchu. Ataki często wykorzystują bowiem wiele wektorów jednocześnie.

 

Warto wdrożyć wyspecjalizowane usługi z zakresu cyberbezpieczeństwa, takie jak:

 

• Netia Managed WAF – ochrona aplikacji webowych na poziomie ruchu HTTP, filtruje żądania i blokuje próby wykorzystania podatności,
• Netia Security Operations Center – całodobowe centrum monitorowania bezpieczeństwa, które analizuje zdarzenia i reaguje na incydenty,
• Netia Incident Monitoring – bieżące monitorowanie, raportowanie i powiadamianie o incydentach, skracające czas reakcji na zagrożenia,
• Netia Managed EDR – usługa wdrożona na serwerze aplikacyjnym lub webowym, która na bieżąco monitoruje procesy systemowe i wykrywa podejrzaną aktywność w czasie rzeczywistym.

 

Wymienione rozwiązania z zakresu cyberbezpieczeństwa działają komplementarnie wobec mechanizmów, takich jak CSP. Warto je też uzupełniać o regularne skanowanie sieci i aplikacji webowych w celu wykrywania podatności.