Analizator CSP

Analizuj Content-Security-Policy (CSP) i Content-Security-Policy-Report-Only dla dowolnego adresu URL. Wykrywaj ryzykowne dyrektywy (unsafe-inline, symbole wieloznaczne), brakujące strategie nonce/hash, przestarzałe wzorce i uzyskaj praktyczne rekomendacje do wzmocnienia ochrony przed XSS. Obsługuje przekierowania, inspekcję surowych nagłówków, filtrowanie, ustalenia oraz eksport do JSON/PDF.

Loading…

O nas Analizator CSP

Wklej adres URL, aby sprawdzić jego nagłówki CSP i szybko zobaczyć, czy polityka rzeczywiście chroni Cię przed XSS i wstrzyknięciami. Ten analizator podświetla niebezpieczne zezwolenia (jak unsafe-inline lub szerokie symbole wieloznaczne), wyjaśnia, czego brakuje (strategia nonce/hash, ograniczenia ramek) i pomaga przejść do praktycznej, wdrażalnej CSP, bezpiecznie korzystając z report-only.

Funkcje

Wykrywaj i wyjaśniaj nagłówki Content-Security-Policy i Content-Security-Policy-Report-Only.
Oznaczaj typowe pułapki CSP: unsafe-inline, unsafe-eval, szerokie symbole wieloznaczne i zbyt permisywne źródła.
Wskazówki dotyczące bezpieczniejszego wykonywania skryptów/styli poprzez strategie oparte na nonce i hash.
Identyfikuj brakujące dyrektywy, które często mają znaczenie w rzeczywistym wzmacnianiu bezpieczeństwa (np. frame-ancestors, object-src, base-uri).
Wgląd w Report-Only: zrozum, co zostałoby zablokowane i jak wdrożyć CSP bez przerywania działania produkcji.
Obserwuj przekierowania (do 10), aby analizować ostateczną politykę odpowiedzi stosowaną przez przeglądarki.
Widok surowych nagłówków dla dokładnego wyniku serwera i debugowania.
Ustalenia + karta wyników z filtrowaniem "tylko problemy".
Eksportuj analizę do JSON lub PDF na potrzeby audytów, zgłoszeń i przeglądów bezpieczeństwa.
Zawiera świadomość przestarzałych nagłówków, aby wychwycić starsze polityki i potrzeby migracji.

🧭 Jak używać for csp-analyzer

Wprowadź adres URL do analizy

Wklej adres URL strony, którą chcesz sprawdzić (często Twoja strona główna lub powłoka aplikacji).

Włącz śledzenie przekierowań, jeśli to konieczne

Pozostaw włączoną opcję "Śledź Przekierowania", aby analizator dotarł do ostatecznego celu HTTPS/www/lokalizacji, gdzie zwracana jest rzeczywista CSP.

Przejrzyj kartę wyników i ustalenia

Zacznij od ustaleń, aby wykryć krytyczne ryzyka (unsafe-inline, symbole wieloznaczne, brakujące ograniczenia) i zrozumieć, które dyrektywy wpływają na wynik.

Sprawdź surowe nagłówki podczas debugowania

Włącz "Pokaż Surowe Nagłówki", aby zweryfikować dokładne nazwy/wartości nagłówków (przydatne, jeśli obecnych jest wiele nagłówków CSP lub proxy/CDN je modyfikuje).

Eksportuj raport dla swojego przepływu pracy bezpieczeństwa

Pobierz JSON do automatyzacji lub PDF na potrzeby audytów bezpieczeństwa i zgłoszeń inżynieryjnych.

Specyfikacje techniczne

Model żądania

To narzędzie wykonuje inspekcję nagłówków adresu URL i koncentruje się na analizie nagłówków bezpieczeństwa, w tym polityk CSP i report-only.

Ustawienie	Zachowanie	Domyślne
Obsługa przekierowań	Podąża za łańcuchem przekierowań, aby przeanalizować efektywną politykę zwróconą przez końcowy adres URL	Włączone
Maks. przekierowania	Limit przekierowań zapobiegający pętlom	10
Limit czasu	Limit czasu żądania	15000 ms
User-Agent	Identyfikuje agenta użytkownika żądania	Encode64Bot/1.0 (+https://encode64.com)
Sieci prywatne	Blokuje dostęp do zakresów sieci prywatnych dla bezpieczeństwa	Wyłączone (sieci prywatne niedozwolone)

Sprawdzane nagłówki CSP

Analizator sprawdza zarówno polityki wymuszające, jak i niewymuszające, i przedstawia je w czytelnej formie.

Nagłówek	Znaczenie
Content-Security-Policy	Wymuszona polityka stosowana przez przeglądarkę
Content-Security-Policy-Report-Only	Nieblokująca polityka zgłaszająca naruszenia (przydatna przy wdrażaniu i dostrajaniu)

Strony mogą wysyłać wiele nagłówków CSP. Przeglądarki stosują zasady łączenia/pierwszeństwa, które mogą być skomplikowane — surowe nagłówki pomagają potwierdzić, co jest wysyłane.

Czego szuka analiza

Wnioski opierają się na praktycznych kontrolach wzmocnienia CSP i typowych błędach wdrożeniowych.

Obszar	Przykłady ustaleń
Siła polityki skryptów	użycie unsafe-inline / unsafe-eval, źródła z symbolami wieloznacznymi, brak strategii nonce/hash
Siła polityki stylów	wbudowane style unsafe-inline, zbyt szerokie źródła, brak ścieżki migracji do nonces/hashes tam, gdzie to możliwe
Odporność na ramkowanie i clickjacking	Brakujące lub słabe ograniczenia ramek (często przez frame-ancestors)
Przestarzałe wzorce	Stare dyrektywy lub wzorce, które należy zmodernizować
Gotowość do wdrożenia	Widoczność nagłówków Report-Only i punktów końcowych raportowania

Wiersz poleceń

Użyj tych poleceń, aby szybko sprawdzić nagłówki CSP. Są przydatne do weryfikacji tego, co zgłasza analizator.

macOS / Linux

Pobierz nagłówki odpowiedzi (szukaj CSP)

curl -I https://example.com

Sprawdź nagłówki Content-Security-Policy i Content-Security-Policy-Report-Only w odpowiedzi.

Obserwuj przekierowania podczas sprawdzania nagłówków

curl -IL https://example.com

Zapewnia, że zobaczysz nagłówki CSP z ostatecznego miejsca docelowego (HTTPS, www, trasa powłoki aplikacji).

Pokaż tylko nagłówki CSP (dopasowanie bez uwzględniania wielkości liter)

curl -I https://example.com | grep -i "content-security-policy"

Szybko wyodrębnia nagłówki CSP i report-only z pełnego zestawu nagłówków.

Windows (PowerShell)

Sprawdź nagłówki CSP

$r = Invoke-WebRequest -Uri https://example.com -Method Head; $r.Headers['Content-Security-Policy']; $r.Headers['Content-Security-Policy-Report-Only']

Wyświetla nagłówki CSP wymuszające i report-only, jeśli są obecne.

Najpierw wdrażaj nowe polityki w trybie Report-Only, przejrzyj raporty o naruszeniach, a następnie zaostrz i wymuś. Dostrajanie CSP dla nowoczesnych aplikacji jest procesem iteracyjnym.

Przykłady zastosowań

Zabezpiecz stronę przed XSS

Użyj CSP, aby ograniczyć wpływ luk wstrzykiwania, ograniczając źródła ładowania skryptów/styli oraz sposób obsługi kodu inline.

Zidentyfikuj unsafe-inline/unsafe-eval i zaplanuj migrację na nonce/hashe
Ogranicz źródła script-src/style-src do zaufanych pochodzeń
Dodaj brakujące dyrektywy obronne (base-uri, object-src, frame-ancestors)

Bezpieczne wdrażanie CSP z Report-Only

Wprowadzaj CSP stopniowo, bez przerywania działania produkcji, zaczynając od Content-Security-Policy-Report-Only i iterując po naruszeniach.

Wykryj obecność polityki report-only
Zrozum, co zostałoby zablokowane przed wymuszeniem
Eksportuj raport dla swojego planu wdrożenia i zgłoszeń

Debugowanie uszkodzonych skryptów, iframe'ów lub widżetów stron trzecich

Zbyt restrykcyjne CSP może blokować analitykę, osadzenia lub połączenia API. Użyj analizatora, aby zobaczyć, co polityka zezwala i gdzie możesz potrzebować jawnych źródeł.

Potwierdź dozwolone źródła skryptów/obrazów/połączeń/ramek
Wykryj zbyt szerokie symbole wieloznaczne dodane jako szybka poprawka
Zastąp szerokie zezwolenia ukierunkowanymi domenami

Przegląd bezpieczeństwa / dowód zgodności

Wygeneruj spójny raport aktualnego stanu CSP na potrzeby przeglądów bezpieczeństwa, kwestionariuszy klientów lub wewnętrznej zgodności.

Pobierz JSON do śledzenia zmian w czasie
Pobierz PDF do artefaktów audytu i udostępniania

❓ Frequently Asked Questions

❓Czym jest CSP i przed czym chroni?

Content Security Policy (CSP) to warstwa bezpieczeństwa wymuszana przez przeglądarkę, która ogranicza źródła ładowania zasobów oraz sposób wykonywania skryptów i stylów. Służy głównie do ograniczania skutków ataków cross-site scripting (XSS) i ataków iniekcji.

❓Jaka jest różnica między CSP a CSP Report-Only?

Content-Security-Policy jest wymuszane (może blokować). Content-Security-Policy-Report-Only nie blokuje; zgłasza naruszenia, aby można było dostroić politykę przed jej wymuszeniem.

❓Dlaczego unsafe-inline jest uważane za niebezpieczne?

unsafe-inline pozwala na skrypty i style wbudowane, co osłabia zdolność CSP do blokowania wstrzykniętego kodu. Bezpieczniejsze podejścia wykorzystują nonce lub hashe, aby zezwolić tylko na znane bloki wbudowane, jednocześnie blokując nieoczekiwane iniekcje.

❓Czy potrzebuję nonce lub hashów?

Jeśli Twoja aplikacja używa wbudowanych skryptów lub stylów, nonce/hashe są nowoczesnym sposobem na utrzymanie skuteczności CSP bez łamania funkcjonalności. Pozwalają one na konkretne bloki wbudowane, zapobiegając jednocześnie dowolnej iniekcji.

❓Czy CDN lub proxy może zmienić mój nagłówek CSP?

Tak. Warstwy brzegowe mogą dodawać, scalać lub nadpisywać nagłówki. Jeśli coś wygląda niespójnie, włącz surowe nagłówki i śledź przekierowania, aby zweryfikować ostateczne nagłówki odpowiedzi.

❓Czy CSP zastępuje naprawę błędów XSS?

Nie. CSP jest kontrolą obrony w głąb. Nadal potrzebujesz właściwego kodowania wyjścia, bezpiecznych szablonów i walidacji wejścia. CSP zmniejsza obszar rażenia, jeśli coś się przedostanie.

❓Czy bezpiecznie jest wklejać tutaj adresy URL?

Narzędzie wykonuje żądania po stronie serwera do podanego adresu URL i blokuje cele w sieciach prywatnych. Unikaj umieszczania sekretów w adresach URL (jak tokeny w ciągach zapytań) i preferuj publiczne adresy URL, którym ufasz.

Pro Tips

Best Practice

Zacznij od Content-Security-Policy-Report-Only, zbierz naruszenia, a następnie zaostrz i wymuś. CSP jest iteracyjne dla prawdziwych aplikacji.

Best Practice

Zastąp unsafe-inline strategią nonce lub hash. Utrzymuj polityki wyraźne i minimalne.

Best Practice

Dodaj frame-ancestors, aby zmniejszyć ryzyko clickjackingu i unikaj polegania tylko na starszych nagłówkach.

Best Practice

Unikaj szerokich symboli wieloznacznych jako szybkiej naprawy. Preferuj docelowe domeny dla skryptów/obrazów/połączeń i przejrzyj potrzeby stron trzecich.

CI Tip

Eksportuj raport JSON i śledź zmiany CSP w CI, aby wychwycić regresje, gdy nagłówki są modyfikowane przez aktualizacje CDN/aplikacji.