Content Security Policy (CSP)

Wprowadzenie

Content Security Policy (CSP) to standard bezpieczeństwa web, który pomaga zapobiegać szerokiej gamie ataków typu cross-site scripting (XSS) oraz innym atakom wstrzykiwania danych. Działa poprzez umożliwienie administratorom serwerów określenia, które zasoby (takie jak skrypty JavaScript, arkusze stylów CSS, obrazy, ramki czy połączenia sieciowe) mogą być ładowane przez przeglądarkę użytkownika. Jest to efektywna warstwa obrony, uzupełniająca tradycyjne mechanizmy walidacji danych wejściowych i sanitacji. CSP została zaprojektowana, aby zmniejszyć ryzyko wykorzystania luk bezpieczeństwa, które umożliwiają atakującym wstrzykiwanie złośliwego kodu do stron internetowych. Poprzez precyzyjne definiowanie zaufanych źródeł treści, CSP znacząco ogranicza powierzchnię ataku, czyniąc witryny bardziej odpornymi na manipulacje i kradzież danych.

Jak działają Content Security Policy?

Content Security Policy jest implementowana poprzez nagłówek HTTP o nazwie `Content-Security-Policy`, wysyłany przez serwer wraz z odpowiedzią HTML. Nagłówek ten zawiera zestaw dyrektyw, które określają dozwolone źródła dla poszczególnych typów zasobów. Kiedy przeglądarka użytkownika otrzymuje ten nagłówek, analizuje go i stosuje zdefiniowane w nim zasady, blokując ładowanie treści pochodzących z niezaufanych źródeł. Podstawą działania CSP są dyrektywy. Przykładowo, dyrektywa `script-src` kontroluje źródła skryptów, `style-src` – arkuszy stylów, `img-src` – obrazów, a `connect-src` – połączeń sieciowych (np. przez `XMLHttpRequest`, WebSockets). Dyrektywa `default-src` działa jako domyślne ustawienie dla wszystkich typów zasobów, które nie mają specyficznie zdefiniowanej dyrektywy. Wartości dyrektyw mogą obejmować konkretne domeny, protokoły (np. `https:`), specjalne słowa kluczowe (`'self'` dla tej samej domeny, `'none'` dla blokowania) lub kryptograficzne nonces/hashe dla inline'owych skryptów i stylów. Przeglądarka egzekwuje te zasady w czasie rzeczywistym. Jeśli strona próbuje załadować skrypt, obraz lub inny zasób z źródła, które nie jest dozwolone przez politykę CSP, przeglądarka blokuje to żądanie i generuje błąd, często wysyłając raport na wskazany adres URL (zdefiniowany przez dyrektywę `report-uri` lub `report-to`). Istnieje również tryb `Content-Security-Policy-Report-Only`, który pozwala testować politykę bez faktycznego blokowania treści, jedynie generując raporty.

Główne zalety i charakterystyka

Główną zaletą Content Security Policy jest znaczące zwiększenie odporności aplikacji webowych na ataki XSS. Dzięki whitelistingowi zaufanych źródeł, CSP skutecznie uniemożliwia wstrzykiwanie i wykonywanie złośliwego kodu, nawet jeśli w aplikacji istnieje luka pozwalająca na injectowanie danych. Jest to szczególnie ważne w kontekście dynamicznie generowanych treści. Dodatkowo, CSP redukuje ogólną powierzchnię ataku, eliminując wiele wektorów zagrożeń, które polegają na nieautoryzowanym ładowaniu zasobów. Pozwala to na większą kontrolę nad tym, co jest wykonywane w przeglądarce użytkownika, co przekłada się na lepsze bezpieczeństwo danych i prywatności. CSP wspiera również inne praktyki bezpieczeństwa, takie jak wymuszanie użycia HTTPS (`upgrade-insecure-requests`), co przyczynia się do budowania bezpieczniejszego środowiska webowego.

Zastosowania w praktyce

• Zapobieganie atakom Cross-Site Scripting (XSS) poprzez blokowanie wykonywania skryptów z niezaufanych źródeł.
• Ograniczenie ładowania zasobów (skryptów, stylów, obrazów) tylko do predefiniowanych domen, co chroni przed niechcianymi treściami stron trzecich.
• Wymuszanie użycia połączeń HTTPS dla wszystkich zasobów (`upgrade-insecure-requests`), zwiększając prywatność i integralność danych.
• Ochrona przed clickjackingiem i atakiami UI redressing poprzez kontrolę, czy strona może być osadzana w ramkach (`frame-ancestors`).
• Kontrola nad źródłami połączeń WebSocket i Web Worker, zapobiegając nieautoryzowanym komunikacjom.

Porównanie z innymi strukturami danych

Content Security Policy różni się od innych mechanizmów bezpieczeństwa web, takich jak walidacja danych wejściowych czy sanitacja danych wyjściowych, które działają głównie po stronie serwera. CSP jest mechanizmem po stronie klienta (przeglądarki), stanowiącym dodatkową, potężną warstwę obrony. Podczas gdy walidacja i sanitacja mają na celu zapobieganie wstrzykiwaniu złośliwego kodu *do* aplikacji, CSP koncentruje się na zapobieganiu *wykonywaniu* tego kodu *przez* przeglądarkę, nawet jeśli jakimś cudem uda mu się znaleźć na stronie. W porównaniu do starszych nagłówków bezpieczeństwa, takich jak `X-XSS-Protection` (który jest przestarzały i może wprowadzać luki) czy `X-Frame-Options` (który kontroluje jedynie osadzanie w ramkach), CSP jest znacznie bardziej kompleksowe i elastyczne. Oferuje granularną kontrolę nad różnymi typami zasobów i zachowań przeglądarki, pozwalając na stworzenie spójnej i wszechstronnej polityki bezpieczeństwa, która obejmuje wiele aspektów naraz.

Najlepsze praktyki (2026)

• Zacznij od trybu `Content-Security-Policy-Report-Only`, aby monitorować naruszenia polityki bez blokowania treści i zbierać dane o brakujących źródłach.
• Używaj jak najostrzejszych dyrektyw, zaczynając od `'self'` i stopniowo dodając tylko niezbędne, zaufane źródła dla każdego typu zasobu.
• Unikaj `unsafe-inline` i `unsafe-eval`. Zamiast tego używaj nonce'ów (kryptograficznych jednorazowych wartości) lub hashy SHA dla inline'owych skryptów i stylów, aby autoryzować tylko konkretne, bezpieczne fragmenty kodu.
• Regularnie przeglądaj i aktualizuj swoją politykę CSP, szczególnie po zmianach w infrastrukturze lub dodaniu nowych bibliotek/zasobów zewnętrznych.
• Wdrażaj `default-src 'none'` i następnie stopniowo zezwalaj na konkretne źródła dla każdego typu zasobu, co zapewnia maksymalne bezpieczeństwo.

Typowe błędy i pułapki

• Tworzenie zbyt ogólnych polityk (np. `script-src *` lub `default-src *`), które praktycznie uniemożliwiają skuteczną ochronę przed XSS.
• Nieużywanie nonce'ów lub hashy dla inline'owych skryptów i stylów, co zmusza do użycia `unsafe-inline` i osłabia bezpieczeństwo.
• Brak dyrektywy `default-src`, co może prowadzić do niezamierzonego dziedziczenia zbyt liberalnych uprawnień dla niezdefiniowanych typów zasobów.
• Wdrażanie zbyt restrykcyjnej polityki od razu w trybie `enforce`, co może zablokować działanie kluczowych funkcji strony dla użytkowników.
• Ignorowanie raportów z `report-uri` lub `report-to`, co uniemożliwia wykrycie błędów w konfiguracji CSP lub prób ataków.