Analizator nagłówków HTTP pokazuje metadane zwracane przez serwer dla danego adresu URL. Screpy wysyła jedno publiczne żądanie GET, podąża za obsługiwanymi przekierowaniami i wyświetla nazwy oraz wartości nagłówków końcowej odpowiedzi bez pobierania treści strony. Raport pomoże zbadać przekierowanie, sprawdzić zmianę nagłówka po wdrożeniu lub znaleźć nieoczekiwaną instrukcję indeksowania.
Zacznij od otrzymanej odpowiedzi, a następnie porównaj ją z tym, co powinien zwracać dany zasób. Ukończone sprawdzenie może ujawnić błąd serwera albo niewłaściwą politykę. Zielony wynik nie potwierdza bezpieczeństwa, wydajności pamięci podręcznej ani indeksowania.
Sprawdź dokładny adres i łańcuch odpowiedzi
Wpisz pełny publiczny adres HTTP lub HTTPS z odpowiednią ścieżką i parametrami. Strona główna, PDF i strona produktu mogą zwracać różne nagłówki w tej samej domenie. Dla fikcyjnej strony produktu https://example.com/products/blue-mug/ jest lepszym adresem niż katalog główny, jeśli chcesz zbadać właśnie tę odpowiedź.
Przeczytaj łańcuch przed tabelą nagłówków. Przekierowanie może zmienić protokół, host lub ścieżkę. Tabela zawiera nagłówki końcowej odpowiedzi, a nie wszystkie nagłówki każdego kroku. Łańcuch obejmuje też odpowiedź końcową, więc liczba kroków nie musi być równa liczbie przekierowań.
Potwierdź, że końcowy adres prowadzi do właściwego zasobu. Strona logowania, błędu lub inny host mogą tłumaczyć nieoczekiwane wartości. Użyj Redirect Checker, gdy potrzebujesz dokładniejszego przeglądu ścieżki przekierowań zamiast końcowej listy nagłówków.
Przeczytaj przykład odpowiedzi HTTP
Ta fikcyjna odpowiedź pokazuje, że poszczególne pola odpowiadają na różne pytania. Nie jest zapisem skanowania ani konfiguracją do kopiowania na każdą stronę.
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
X-Robots-Tag: noindex
Kod 200 oznacza pomyślną odpowiedź. Content-Type deklaruje HTML z kodowaniem UTF-8. Cache-Control opisuje instrukcje pamięci podręcznej, a X-Robots-Tag przekazuje instrukcję indeksowania. Działająca odpowiedź może więc zawierać noindex: sukces HTTP nie oznacza, że strona ma pojawiać się w wyszukiwarce.
Tabela normalizuje nazwy do małych liter; wielkość liter nie tworzy odrębnych pól. Dokumentacja nagłówków MDN rozróżnia pola żądania i odpowiedzi. Analizator pokazuje odpowiedź, a nie pliki cookie, preferencje czy dane uwierzytelniania z Twojej sesji przeglądarki.
Oceniaj pamięć podręczną i indeksowanie oddzielnie
Przy konkretnym problemie filtruj tabelę po nazwie nagłówka. Najpierw określ potrzeby zasobu: często zmieniany HTML, plik z wersją i dokument celowo wykluczony z wyszukiwarki nie muszą korzystać z jednej polityki.
| Nagłówek | Przydatne pytanie podczas kontroli |
|---|---|
content-type |
Czy deklarowany format pasuje do oczekiwanego zasobu, czy przekierowanie dotarło do innej odpowiedzi? |
cache-control |
Czy polityka odpowiada wymaganiom aktualizacji i prywatności zasobu? |
etag lub last-modified |
Czy istnieje walidator dla żądań warunkowych? Sama obecność nie testuje ponownej walidacji. |
vary |
Jakie różnice nagłówków żądania wskazano przy wyborze odpowiedzi z pamięci podręcznej? |
x-robots-tag |
Czy zaobserwowane noindex jest zamierzone dla tego adresu? |
no-cache nie oznacza „nigdy nie zapisuj”. Pozwala przechowywać odpowiedź, ale wymaga walidacji przed ponownym użyciem. no-store nakazuje pamięciom podręcznym nie przechowywać odpowiedzi. Opis Cache-Control w MDN wyjaśnia różnicę. To sprawdzenie nie mierzy trafień pamięci podręcznej ani nie usuwa zapisanych wcześniej kopii.
Instrukcja indeksowania jest odrębna od aktualności treści. Jeśli strona przeznaczona do indeksowania niespodziewanie zwraca noindex, przed zmianą znajdź odpowiedzialną aplikację, ustawienie serwera lub regułę odpowiedzi. Użyj Noindex Checker, aby zbadać także dyrektywy HTML. Dokumentacja noindex Google opisuje instrukcję; jej wykrycie nie ustala obecnego stanu indeksu Google.
Zrozum obserwacje dotyczące nagłówków bezpieczeństwa
Screpy wskazuje wybrane deklaracje do sprawdzenia. Traktuj wynik jako pytanie o konfigurację, nie raport podatności ani zalecenie wklejenia nieznanej polityki do działającej witryny.
| Obserwacja | Co sprawdzenie ustala, a czego nie |
|---|---|
| Kontrola HSTS | Szuka dodatniego max-age w odpowiedzi HTTPS. Nie weryfikuje całego wdrożenia HTTPS ani certyfikatów. |
| Brak CSP | Szuka Content-Security-Policy w odpowiedzi zadeklarowanej jako HTML. Obecność nie gwarantuje ochrony aplikacji przez dyrektywy. |
| Kontrola osadzania | Szuka frame-ancestors w CSP lub rozpoznanej wartości X-Frame-Options. Możliwość osadzania zależy od przeznaczenia strony. |
| Kontrola rozpoznawania MIME | Sprawdza, czy X-Content-Type-Options deklaruje nosniff. Nie bada rzeczywistej treści pliku ani zachowania każdej przeglądarki. |
Informacja lub brak polityki nie dowodzą podatności. Również obecny nagłówek nie sprawia automatycznie, że polityka działa. Dokumentacja CSP w MDN odróżnia polityki egzekwowane od Content-Security-Policy-Report-Only, które raportuje naruszenia bez narzucania tych ograniczeń. Samo wykrycie tego drugiego nie potwierdza polityki egzekwującej ograniczenia.
Oceniaj zmiany według rzeczywistych potrzeb aplikacji dotyczących zasobów i osadzania. Analizator nie przyznaje oceny bezpieczeństwa, nie bada certyfikatów ani nie weryfikuje każdej dyrektywy. Niezabezpieczone odwołania do zasobów w HTML sprawdź oddzielnie za pomocą Mixed Content Checker.
Interpretuj powtarzające się i ukryte wartości
Liczba nagłówków dotyczy różnych znormalizowanych nazw. Kolumna wystąpień pokazuje, ile razy pojawiła się nazwa, a zwykłe powtórzone wartości pozostają widoczne. Kilka wystąpień nie oznacza automatycznie błędu: sprawdź, czy dane pole dopuszcza taką strukturę i czy połączona polityka jest zamierzona.
Poufne wartości cookie, uwierzytelniania i rozpoznanych sekretów są ukrywane lub oczyszczane. Ukryta wartość nie jest brakującym nagłówkiem, a jej obecność nie stanowi oceny bezpieczeństwa cookie. Nie uzupełniaj zamaskowanych danych w udostępnianym raporcie. Poufne szczegóły analizuj wyłącznie w odpowiednim prywatnym środowisku diagnostycznym.
Filtruj po nazwie, np. cache-control, zamiast oczekiwać przeszukiwania wszystkich wartości. Zachowaj raport z adresem i czasem sprawdzenia, aby porównywać odpowiedzi. Obecność lub brak pola interpretuj razem z końcowym kodem, typem zasobu i informacją o zakresie.
Odróżnij częściowe sprawdzenie od błędu HTTP
Błąd zwrócony przez serwer różni się od sytuacji, gdy analizator nie może do niego dotrzeć. Przeczytaj informację o zakresie przed oceną brakujących wierszy.
| Wynik | Znaczenie i kolejny krok |
|---|---|
Końcowe 404 lub 500 z nagłówkami |
Zaobserwowano odpowiedź. Potwierdź adres i zbadaj błąd zasobu lub serwera; działające połączenie nie oznacza działającej strony. |
| Częściowy łańcuch | Zaobserwowano pewne kroki, ale nie sprawdzono końcowej odpowiedzi. Końcowe nagłówki są niedostępne, nie na pewno nieobecne. |
| Przekroczony czas lub niedostępne źródło | Nie uzyskano żądanej odpowiedzi. Przed powtórzeniem sprawdź publiczny dostęp, adres i przekierowania. |
Analizator śledzi ograniczoną liczbę przekierowań i czeka przez ograniczony czas. Pętle, niedostępne cele lub odpowiedzi przekraczające obsługiwane limity mogą pozostawić sprawdzenie niekompletne. Pusta końcowa lista nie jest wtedy listą brakujących nagłówków bezpieczeństwa.
Prywatne adresy sieciowe, strony wymagające logowania i żądania potrzebujące Twoich cookie są poza zakresem formularza. Ograniczenie dostępu nie dowodzi też, co otrzymuje Googlebot lub inny rzeczywisty odwiedzający.
Porównuj nagłówki po wdrożeniu
Przed zmianą zanotuj dokładny adres, końcową odpowiedź, czas oraz pole, które ma się zmienić. Wyeksportuj raport jako punkt odniesienia. Po opublikowaniu zamierzonej konfiguracji sprawdź ten sam adres i porównaj właściwe wartości, a nie tylko liczbę nagłówków czy ostrzeżeń. Powtórz dla innego typu zasobu, jeśli reguła ma obowiązywać także tam.
Jeśli przeglądarka pokazuje coś innego, otwórz panel Sieć, odśwież stronę i zbadaj odpowiednie żądanie. Porównaj adres po przekierowaniach, metodę i stan logowania. Spersonalizowana odpowiedź lub kopia z pamięci podręcznej może różnić się od publicznego żądania z innej lokalizacji. Formularz nie wysyła Twoich cookie i nie pozwala dodawać własnych nagłówków uwierzytelniania.
Sprawdź również, czy inne narzędzie używało HEAD zamiast GET. RFC 9110 wyjaśnia, że HEAD nie zawiera treści i może pomijać pola ustalane podczas generowania zawartości. Screpy używa GET, lecz zatrzymuje się przed pobraniem treści. Dopasowanie metody i warunków pomaga zbadać różnicę; nie sprawia, że wszystkie odpowiedzi serwera są identyczne.