Sprawdź Content-Security-Policy dyrektywa po dyrektywie i zobacz, jak skrypty ją omijają
Działa w przeglądarce. Wpisane dane nie są nigdzie wysyłane. Sprawdzono 16 października 2026.Content-Security-Policy mówi przeglądarce, skąd można ładować skrypty i inne treści. Chroni przed wstrzykniętymi skryptami tylko wtedy, gdy script-src unika 'unsafe-inline', symboli wieloznacznych i hostów umożliwiających obejście, object-src ma wartość 'none', a base-uri jest ograniczone. Badanie Google z 2016 roku wykazało, że 94.7% rzeczywistych polityk dało się obejść; nonce z 'strict-dynamic' rozwiązują ten problem.
Ta strona została przetłumaczona maszynowo z angielskiego oryginału. Tłumaczenie nie zostało jeszcze sprawdzone przez człowieka, dlatego wiążąca jest wersja angielska. Przeczytaj angielski oryginał
Wklej politykę, cały wiersz nagłówka Content-Security-Policy lub tag <meta>, który ją zawiera.
Przeczytaj wyniki, od najpoważniejszych: każdy wskazuje dyrektywę i to, co atakujący mógłby z nią zrobić.
Sprawdź w tabeli dyrektyw błędnie zapisane nazwy i źródła, które przeglądarka zignoruje.
Popraw politykę lub zacznij od ścisłego szablonu i wklej ją ponownie, aż zostaną tylko uwagi.
W Content-Security-Policy łatwo o subtelny błąd, a przeglądarki nigdy się nie skarżą: dyrektywa, której nie potrafią odczytać, jest ignorowana. To narzędzie odczytuje politykę dokładnie tak, jak według specyfikacji CSP Level 3 robi to przeglądarka, a następnie ocenia ją na podstawie wyników badania rzeczywistych polityk przeprowadzonego przez Google w 2016 roku.
Wyniki, od najpoważniejszych.
| Waga | Przykłady |
|---|---|
| Wysoka | 'unsafe-inline' bez nonce, * lub https: w script-src, object-src inne niż 'none', 'strict-dynamic' bez nonce, brakujący średnik, self bez cudzysłowów |
| Średnia | 'unsafe-eval', dozwolone hosty znane z udostępniania JSONP lub starego AngularJS, otwarte base-uri, źródła przez zwykłe http, nieznane dyrektywy |
| Niska | brak frame-ancestors, krótkie nonce, przestarzałe dyrektywy, duplikaty, 'unsafe-inline' dla stylów |
| Uwaga | brak raportowania, report-uri bez report-to, źródła ignorowane przez przeglądarki przy ścisłej polityce |
Stosowany jest mechanizm zastępczy. Gdy brakuje script-src, w jego miejsce oceniane jest default-src; gdy brakuje obu, skrypty mogą być ładowane z dowolnego miejsca i narzędzie o tym informuje.
Można wkleić cokolwiek. Samą politykę, cały wiersz nagłówka lub tag <meta http-equiv>. Polityki dostarczane w tagu meta nie mogą używać frame-ancestors, report-uri ani sandbox, a narzędzie to oznacza. Nagłówek z kilkoma politykami rozdzielonymi przecinkami jest dzielony, ponieważ każda z nich jest egzekwowana.
Każde źródło jest sprawdzane. Słowa kluczowe, nonce, hashe (z właściwą długością dla SHA-256, 384 lub 512), schematy i hosty są sprawdzane względem gramatyki, a dla błędnie zapisanej dyrektywy pojawia się podpowiedź, na przykład frame-ancestor na frame-ancestors.
Ścisły szablon. Jedno dotknięcie wczytuje politykę opartą na nonce: script-src z nonce i 'strict-dynamic', object-src 'none' oraz base-uri 'none'. Serwer musi przy każdej odpowiedzi wpisywać nowy losowy nonce do nagłówka i do każdego tagu script.
Polityka jest odczytywana w przeglądarce i nigdy nie jest nigdzie wysyłana. Aby pobrać nagłówki wysyłane przez działającą witrynę, można użyć narzędzia HTTP Headers Checker.
Nie. Przy 'unsafe-inline' uruchamia się każdy skrypt, który atakującemu uda się wstrzyknąć do strony, a właśnie temu ma zapobiegać Content-Security-Policy. Zamiast tego należy użyć nonce lub hasha dla każdego skryptu inline. Gdy obecny jest nonce lub hash, nowoczesne przeglądarki ignorują 'unsafe-inline', więc pozostawienie go jako zabezpieczenia dla starych przeglądarek jest nieszkodliwe.
Słowo kluczowe 'strict-dynamic' pozwala skryptowi zaufanemu dzięki nonce lub hashowi ładować kolejne skrypty, a listy dozwolonych hostów i https: są ignorowane przez przeglądarki, które je obsługują. W połączeniu z nonce daje politykę jednocześnie ścisłą i łatwą do wdrożenia. Bez żadnego nonce ani hasha blokuje każdy skrypt.
Wtyczki ładowane tagami object lub embed mogą uruchamiać skrypty poza regułami script-src, a stare pliki Flash na dozwolonych hostach były częstym sposobem obejścia. Niewiele witryn wciąż potrzebuje wtyczek, więc object-src 'none' zamyka całą tę drogę. Jeśli brakuje object-src, obowiązuje default-src, które często nie ma wartości 'none'.
Popularne hosty skryptów, takie jak duże CDN i niektóre domeny Google, udostępniają endpointy JSONP lub stare wersje AngularJS. Atakujący, który może wstrzyknąć znaczniki, może załadować te dozwolone pliki, aby uruchomić własny kod. Badanie Google z 2016 roku wykazało, że 94.7% rzeczywistych polityk opartych na listach hostów dało się w ten sposób obejść; nonce z 'strict-dynamic' pozwalają uniknąć problemu.
Przeglądarka ignoruje dyrektywę i zapisuje ostrzeżenie w konsoli, ale reszta polityki nadal obowiązuje, więc strona po cichu traci tę ochronę. Literówka taka jak frame-ancestor zamiast frame-ancestors zostawia stronę podatną na clickjacking. To narzędzie wyświetla nieznane dyrektywy i podpowiada nazwę, o którą prawdopodobnie chodziło.
Tak, za pomocą tagu meta http-equiv w sekcji head strony, ale trzy dyrektywy tam nie działają: frame-ancestors, report-uri i sandbox. Polityki w tagu meta obowiązują też tylko dla treści po tym tagu. Wysyłanie polityki jako nagłówka odpowiedzi HTTP jest niezawodnym wyborem; tag meta sprawdza się przy hostingu statycznym bez kontroli nad nagłówkami.
Stawki i przepisy się zmieniają; przed oparciem się na danej liczbie należy sprawdzić źródło.
Nadal coś nie działa? Zapytaj o narzędzie Analizator CSP a odpowiedzieć może każdy, kto zna odpowiedź. Konto nie jest potrzebne.