Generator nagłówka CSP

Generator nagłówka CSP — polityka Content-Security-Policy bez zgadywania

Generator nagłówka CSP składa politykę Content-Security-Policy z dziesięciu dyrektyw decydujących o odporności strony na wstrzyknięcia kodu. Wpisz listy źródeł, wybierz nagłówek HTTP albo znacznik <meta> i skopiuj gotową linię do konfiguracji serwera.

Co dokładnie robi to narzędzie

Formularz przyjmuje dziesięć dyrektyw z listami źródeł — od default-src po frame-ancestors. Puste pola są pomijane, nadmiarowe spacje redukowane, a powtórzone źródła w jednej dyrektywie usuwane: nagłówek leci z każdą odpowiedzią, więc jego długość ma znaczenie. Znaki ; i cudzysłowy proste są odfiltrowane, żeby wklejona wartość nie rozbiła listy dyrektyw.

Wynik dostajesz jako linię Content-Security-Policy: … dla serwera albo jako znacznik <meta http-equiv>. Nagłówek HTTP jest wersją pełną: wariant meta nie obsługuje frame-ancestors, report-uri ani sandbox, dlatego generator pomija wtedy tę dyrektywę.

Dyrektywy, które generator ustawia

Dwie pozycje z tej listy domykają typowe obejścia polityki. object-src 'none' wyłącza stare wtyczki, przez które dawało się wykonać kod pomimo restrykcyjnego script-src. base-uri 'self' blokuje podmianę <base href> kierującą względne adresy skryptów na obcy serwer.

Jak wdrożyć CSP i nie zepsuć strony

1. Wyślij politykę najpierw pod nazwą Content-Security-Policy-Report-Only. Przeglądarka nic wtedy nie blokuje, tylko raportuje naruszenia.
2. Przeklikaj serwis, zwłaszcza podstrony z mapami, płatnościami, czatem i wideo — tam wychodzą brakujące domeny.
3. Uzupełnij listy źródeł adresami z raportów i sprawdź, czy nagłówek dociera do przeglądarki: pokaże to analizator nagłówków HTTP.
4. Gdy raporty milczą przez kilka dni normalnego ruchu, zmień nazwę nagłówka na Content-Security-Policy i polityka zaczyna wymuszać reguły.

Nagłówek dodajesz w konfiguracji serwera: na Apache przez Header always set w .htaccess (pomoże generator .htaccess), na nginksie przez add_header w bloku lokalizacji (konfigurator bloków location nginx).

Header always set Content-Security-Policy "default-src 'self'; object-src 'none'"

Dlaczego 'unsafe-inline' w script-src znosi ochronę

CSP zatrzymuje XSS w jednym miejscu: nie pozwala uruchomić skryptu, którego nie zadeklarowałeś. Wstrzyknięty <script>alert(1)</script> jest właśnie skryptem inline. Gdy w script-src pojawi się 'unsafe-inline', przeglądarka wykona każdy kod osadzony w HTML — także ten z pola komentarza. Najczęstszy scenariusz ataku przechodzi wtedy bez przeszkód. To samo dotyczy 'unsafe-eval', które otwiera eval().

Zamiast 'unsafe-inline' użyj jednorazowego nonce: serwer losuje wartość dla każdej odpowiedzi i wpisuje ją do nagłówka oraz w atrybut nonce zaufanych znaczników. Atakujący nie zna tej wartości, więc jego kod się nie wykona. Dla stałych bloków alternatywą jest hash 'sha256-…' z dokładnej treści skryptu — policzysz go generatorem hashy.

frame-ancestors, X-Frame-Options i upgrade-insecure-requests

frame-ancestors określa, kto może umieścić stronę w iframe, i zastępuje starszy X-Frame-Options. Stary nagłówek zna tylko DENY i SAMEORIGIN, nie przyjmuje listy domen, a jego wariant ALLOW-FROM nigdy nie działał w Chrome. Gdy oba są ustawione, przeglądarki honorują CSP.

Warto też dopisać upgrade-insecure-requests. Ta dyrektywa nie ma listy źródeł — jej obecność sprawia, że przeglądarka sama zamienia adresy http:// na https:// przed wysłaniem żądania. Ratuje strony po migracji na HTTPS ze starymi odnośnikami do obrazków po HTTP. Co jeszcze ładuje się bez szyfrowania, sprawdzisz detektorem mixed content.

Najczęściej zadawane pytania