Sprawdzanie Nagłówków HTTP
Narzędzie do sprawdzania nagłówków HTTP wysyła zapytanie pod wskazany adres i pokazuje nagłówki odpowiedzi zwrócone przez serwer: kod statusu, pola pamięci podręcznej i ciasteczek oraz nagłówki bezpieczeństwa, które egzekwuje przeglądarka. To narzędzie dodaje do tego ocenę od 0 do 100 wyliczaną z siedmiu nagłówków: HSTS, CSP, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy i Permissions-Policy. Dla github.com zwraca 200 OK w około 60 ms, 17 nagłówków i wynik 90/100, ocena A+.
Nagłówki Bezpieczeństwa
Wszystkie Nagłówki Odpowiedzi
| Header | Value |
|---|---|
Co pokazuje to narzędzie do sprawdzania nagłówków HTTP?
Wpisz domenę: narzędzie wysyła z naszego serwera zapytanie HEAD pod ten adres, a następnie pokazuje kod statusu, czas obiegu w milisekundach, pełną listę nagłówków odpowiedzi oraz wynik bezpieczeństwa od 0 do 100 zbudowany z HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy i Permissions-Policy. Raportuje to, co wysłał serwer: nie podąża za przekierowaniami i nie czyta treści strony.
Popularne narzędzia
O Sprawdzaniu Nagłówków HTTP
To narzędzie przyjmuje adres URL, wysyła pod niego zapytanie HEAD z naszego serwera i pokazuje wszystko, co wróciło: kod statusu wraz z jego opisem, czas obiegu w milisekundach oraz każdy nagłówek odpowiedzi wysłany przez serwer. Dla github.com jest to 200 OK w około 60 ms i 17 pól nagłówków, od content-type i etag po pełną wartość content-security-policy.
Karta Wynik Bezpieczeństwa ocenia siedem nagłówków w skali do 100. Strict-Transport-Security i Content-Security-Policy warte są po 20 punktów, X-Content-Type-Options i X-Frame-Options po 15, a X-XSS-Protection, Referrer-Policy i Permissions-Policy po 10. Od 90 punktów ocena to A+, od 80 A, od 70 B, od 60 C, od 40 D, a poniżej F. github.com uzyskuje 90/100, bo brakuje Permissions-Policy; example.com nie wysyła żadnego z siedmiu i dostaje 0.
Wynik liczy obecność, nie jakość. Wartość x-xss-protection: 0 wyłącza ten filtr, a mimo to daje swoje dziesięć punktów, natomiast nagłówek content-security-policy-report-only nie daje żadnego — czytaj więc wartości wypisane pod każdym wierszem oznaczonym Present, a nie samą ocenę. Przekierowania nie są śledzone: google.com odpowiada 301 z location: https://www.google.com/, a żeby ocenić cel, trzeba ten adres wkleić samodzielnie. Zapytanie jest typu HEAD, więc żaden kod HTML, znacznik meta ani tekst strony nie jest analizowany; po dziesięciu sekundach zapytanie zostaje przerwane, a z jednego adresu przyjmowanych jest dwadzieścia sprawdzeń na minutę.
Wpisany adres trafia na serwer tej witryny, który wykonuje zapytanie w twoim imieniu z identyfikatorem FreeWebTools Header Checker/1.0 i bez twoich ciasteczek ani sesji, więc widzisz odpowiedź dla anonimowego odwiedzającego. Prywatne i zarezerwowane zakresy adresów IP, localhost, punkty metadanych chmury oraz porty administracyjne takie jak 22, 3306 i 6379 są odrzucane.
Przypadki użycia
Jak sprawdzić nagłówki odpowiedzi HTTP witryny
Wpisz domenę lub pełny adres w pole wyszukiwania, na przykład example.com; przedrostek https:// zostanie dodany automatycznie. Możesz też kliknąć jeden z przykładów obok napisu Wypróbuj: google.com, github.com, cloudflare.com lub stackoverflow.com.
Naciśnij Enter albo kliknij Sprawdź. Zapytanie wychodzi z naszego serwera jako zapytanie HEAD, więc wracają wyłącznie nagłówki, nigdy treść strony.
Przeczytaj trzy karty podsumowania: Kod Statusu wraz z jego opisem, Wynik Bezpieczeństwa na 100 z oceną literową oraz Czas Odpowiedzi w milisekundach.
Przejrzyj sekcję Nagłówki Bezpieczeństwa, aby zobaczyć, które z HSTS, CSP, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy i Permissions-Policy są oznaczone jako Present lub Missing, i przeczytaj wartość pod każdym obecnym.
Otwórz Wszystkie Nagłówki Odpowiedzi, aby przeczytać nazwę i wartość każdego nagłówka zwróconego przez serwer, w tym pola pamięci podręcznej, ciasteczek i CDN, których wynik nie obejmuje.
Kliknij Kopiuj, aby umieścić cały raport — adres, status, wynik z oceną i listę nagłówków — w schowku jako zwykły tekst.
Porady Pro
- Wpisz samą domenę: pole samo dodaje https://, więc github.com jest sprawdzany jako https://github.com. Napisz http:// jawnie, aby zobaczyć odpowiedź po zwykłym HTTP, gdzie strict-transport-security zwykle nie występuje, bo RFC 6797 każe przeglądarkom ignorować go na niezabezpieczonym połączeniu.
- Wynik nagradza obecność, a nie wartość. github.com wysyła x-xss-protection: 0, czyli wyłącza filtr, i mimo to zgarnia pełne dziesięć punktów — przeczytaj szary wiersz z wartością pod każdą pozycją oznaczoną Present, zanim zaufasz ocenie.
- Polityka w trybie report-only nie daje punktów. google.com wysyła content-security-policy-report-only bez polityki egzekwowanej i traci przez to całe 20 punktów za CSP; etykieta Present pojawia się wyłącznie dla dokładnej nazwy nagłówka content-security-policy.
- Gdy karta Kod Statusu pokazuje 301 lub 302, skopiuj wartość location z tabeli nagłówków i uruchom na niej drugie sprawdzenie. Sama odpowiedź przekierowująca prawie nie zawiera nagłówków bezpieczeństwa i właśnie dlatego google.com kończy na 25/100.
- Przycisk Kopiuj umieszcza cały raport w schowku jako zwykły tekst — adres, status, wynik z oceną i każdy nagłówek — czyli dokładnie to, co wkleja się do zgłoszenia. Pracę seryjną rozłóż na dwadzieścia sprawdzeń na minutę; powyżej tego API odpowiada 429, a strona pokazuje ogólny komunikat o błędzie.
Rozwiązywanie problemów
Strona pokazuje „Failed to check headers. Please verify the URL is accessible.”, mimo że witryna otwiera się w przeglądarce normalnie.
Ten ogólny komunikat pojawia się, gdy odpowiedź wróciła bezużyteczna. Najczęstszą przyczyną jest limit zapytań: powyżej dwudziestu sprawdzeń na minutę z tego samego adresu API odpowiada 429 Too Many Requests. Odczekaj minutę i spróbuj ponownie. Ten sam komunikat pojawia się, gdy serwer odpowiada na zapytanie HEAD dłużej niż dziesięciosekundowy limit czasu.
W wierszu błędu widnieje „Connection failed: SSL certificate problem: certificate has expired”.
Certyfikat jest weryfikowany, a nie przyjmowany na ślepo, więc certyfikat wygasły, samopodpisany albo wystawiony na inną nazwę hosta przerywa sprawdzenie zamiast wygenerować mylący raport. Odnów lub popraw certyfikat, albo sprawdź adres z przedrostkiem http://, aby odczytać nagłówki wysyłane przez serwer przed nawiązaniem TLS.
W wierszu błędu widnieje „Internal URLs not allowed”, „Private IPs not allowed” albo „This port is not allowed”.
Narzędzie odrzuca localhost, prywatne i zarezerwowane zakresy adresów IP, punkty metadanych chmury oraz porty 22, 23, 25, 3306, 5432, 6379, 11211, 27017, 8080 i 8443, żeby nie dało się z niego zrobić skanera sieci wewnętrznej. Użyj publicznie rozwiązywalnej nazwy hosta na porcie 80 lub 443; dla serwera lokalnego uruchom curl -I na samej maszynie.
Karta Kod Statusu pokazuje 301 lub 302, tylko garstkę nagłówków i niski wynik bezpieczeństwa.
Przekierowania celowo nie są śledzone, więc oceniasz samą odpowiedź przekierowującą, a nie stronę docelową. google.com odpowiada 301 z location: https://www.google.com/ i właśnie dlatego kończy na 25/100. Skopiuj wartość location z tabeli nagłówków i uruchom na niej drugie sprawdzenie, aby ocenić stronę, na którą naprawdę trafiają odwiedzający.
W wierszu błędu widnieje „Connection failed: Could not resolve host”.
Nasz serwer nie znalazł publicznego wpisu DNS dla tej nazwy hosta. Sprawdź pisownię, usuń spację lub cudzysłów wklejony razem z adresem i upewnij się, że domena rozwiązuje się spoza twojej sieci. Host istniejący wyłącznie w twoim pliku hosts, za VPN-em albo na wewnętrznym serwerze DNS jest stąd nieosiągalny.
Często zadawane pytania
Wpisz domenę w pole na górze tej strony i naciśnij Enter albo kliknij Sprawdź. Nasz serwer wysyła zapytanie HEAD pod ten adres, a strona wypełnia trzy karty — Kod Statusu, Wynik Bezpieczeństwa i Czas Odpowiedzi — po których pojawia się analiza Nagłówki Bezpieczeństwa i tabela wszystkich otrzymanych nagłówków. github.com odpowiada 200 OK w około 60 ms i 17 polami. Nie potrzeba rozszerzenia, polecenia curl ani narzędzi deweloperskich.
Nagłówek HTTP to wiersz złożony z nazwy i wartości, dołączany do zapytania lub odpowiedzi, aby ją opisać. content-type: text/html; charset=utf-8 podaje typ treści, cache-control mówi, jak długo odpowiedź może być używana ponownie, a location wskazuje cel przekierowania. RFC 9110, HTTP Semantics, definiuje składnię pól i rejestr ich nazw. Nagłówki idą obok treści, nigdy w niej; ta strona wypisuje wyłącznie nagłówki odpowiedzi.
Ocenianych jest tu siedem: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy i Permissions-Policy. HSTS i CSP ważą po 20 punktów, X-Content-Type-Options i X-Frame-Options po 15, pozostałe trzy po 10. MDN oznacza X-XSS-Protection jako wycofany i niestandardowy i zaleca zamiast niego mocną Content-Security-Policy, więc tych dziesięć punktów traktuj jako pozostałość po dawnych czasach, a nie cel.
Uruchom sprawdzenie i przeczytaj sekcję Nagłówki Bezpieczeństwa: każdy z siedmiu nagłówków ma etykietę Present albo Missing, jednowierszowy opis oraz — jeśli występuje — dokładną wartość zwróconą przez serwer. Karta Wynik Bezpieczeństwa przelicza to na skalę 0-100 z oceną: od 90 A+, od 80 A, od 70 B, od 60 C, od 40 D, poniżej 40 F. github.com uzyskuje 90/100, brakuje mu tylko Permissions-Policy.
Naciśnij F12, aby otworzyć narzędzia deweloperskie, przejdź na kartę Sieć, odśwież stronę, kliknij zapytanie dokumentu i przeczytaj panel nagłówków odpowiedzi. Widać tam, co otrzymała twoja własna przeglądarka, łącznie z ciasteczkami i negocjacją treści. Ta strona jest neutralnym odpowiednikiem: zapytanie wychodzi z naszego serwera z identyfikatorem FreeWebTools Header Checker/1.0 i bez ciasteczek, więc widzisz to, co dostaje anonimowy odwiedzający.
Nagłówki niosą wszystko, co w komunikacie nie jest treścią: wynik transferu, typ i kodowanie treści, reguły pamięci podręcznej i ponownej walidacji, ciasteczka oraz polityki bezpieczeństwa, które przeglądarka musi egzekwować. Bez content-type przeglądarka musi zgadywać format, bez strict-transport-security może dalej rozmawiać zwykłym HTTP, a bez content-security-policy wstrzyknięty skrypt wykona się bez przeszkód. Sama treść nie wyrazi niczego z tych rzeczy.
Każde pole zajmuje jeden wiersz: nazwa, dwukropek, opcjonalna spacja i wartość, jak w x-frame-options: deny. RFC 9110, sekcja 5.1, czyni nazwy pól niewrażliwymi na wielkość liter, a HTTP/2 wymaga zapisu małymi literami — dlatego w tabeli powyżej widnieje content-type, a nie Content-Type. Pole może się zgodnie z prawem powtarzać; narzędzie zachowuje wtedy ostatnią odczytaną wartość.
Tak. TLS szyfruje cały komunikat HTTP wraz z nagłówkami, więc obserwator sieci widzi docelowy adres IP i nazwę hosta w SNI, ale nie nazwy pól, wartości ani ciasteczka. W zwykłym HTTP nic nie jest chronione i właśnie tym zajmuje się Strict-Transport-Security: RFC 6797 nakazuje przeglądarce używać HTTPS dla tego hosta przez cały okres max-age, a sam nagłówek przeglądarki ignorują, jeśli przyszedł przez HTTP.
Nazwy pól nie. RFC 9110, sekcja 5.1, stwierdza, że nazwy pól są niewrażliwe na wielkość liter: Content-Type i content-type to to samo pole, a HTTP/2 wymusza zapis małymi literami. Z wartościami jest inaczej: przeglądarka przyjmie tak samo x-frame-options: DENY jak deny, ale adres w location, ETag czy nonce w Content-Security-Policy porównywane są dokładnie tak, jak zostały zapisane.
Nie. Ta strona raportuje nagłówki odpowiedzi, ponieważ zapytanie wysyła nasz serwer, a nie twoja przeglądarka. Aby przeczytać nagłówki wysyłane przez twoją przeglądarkę, otwórz narzędzia deweloperskie, przejdź na kartę Sieć i rozwiń nagłówki zapytania albo skorzystaj z usługi odsyłającej zapytanie z powrotem. Wszystko, co widać tutaj — status, wynik i tabela — opisuje wpisaną witrynę, a nie twojego klienta.