Nagłówki bezpieczeństwa HTTP
Sprawdź, czy twoja strona ma poprawnie skonfigurowane nagłówki bezpieczeństwa HTTP.
Jak działa test nagłówków
Narzędzie wysyła zwykłe żądanie HTTPS GET na podany URL i odczytuje nagłówki odpowiedzi - te same, które otrzymuje każda przeglądarka. Nic nie jest parsowane z treści strony; nagłówki bezpieczeństwa żyją wyłącznie w odpowiedzi HTTP.
Następnie szukamy nagłówków sterujących ochroną po stronie przeglądarki: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options i Referrer-Policy. Każdy obecny nagłówek podnosi wynik, a brakujące są wypisane wraz z wyjaśnieniem ryzyka, które pozostawiają otwarte.
Ponieważ test podąża za przekierowaniami, wynik odzwierciedla końcowy URL. Jeśli strona przekierowuje z HTTP na HTTPS albo z gołej domeny na www, widoczne nagłówki należą do celu przekierowania.
Jak czytać wyniki
Wynik punktowy to szybka orientacja, nie certyfikat. Co liczy się w praktyce:
- HSTS - każe przeglądarkom zawsze używać HTTPS dla Twojej domeny. Powszechną praktyką jest max-age co najmniej pół roku; includeSubDomains dodawaj tylko wtedy, gdy każda subdomena działa po HTTPS.
- CSP - najsilniejsza obrona przed XSS, ale też najtrudniejsza do napisania. Nawet podstawowa polityka ograniczająca źródła skryptów to duży postęp w porównaniu z brakiem jakiejkolwiek.
- X-Content-Type-Options: nosniff i X-Frame-Options (lub dyrektywa CSP frame-ancestors) - tanie, jednolinijkowe zabezpieczenia przed MIME sniffingiem i clickjackingiem.
Częste problemy
Nagłówek skonfigurowany, a raportowany jako brakujący. Reverse proxy lub CDN przed aplikacją może usuwać albo nadpisywać nagłówki. Porównaj odpowiedź przez curl -I bezpośrednio z originu i z publicznego URL, aby znaleźć warstwę, która go gubi.
CSP obecne, ale nieskuteczne. Content-Security-Policy-Report-Only tylko loguje naruszenia, niczego nie blokuje. Przydaje się do testów, ale nie daje żadnej ochrony - gdy log raportów będzie czysty, przełącz się na nagłówek wymuszający.
Różne ścieżki zwracają różne nagłówki. Nagłówki ustawiane w middleware aplikacji mogą nie obejmować plików statycznych serwowanych bezpośrednio przez serwer WWW ani stron błędów. Przetestuj też URL zasobu statycznego i stronę 404.
Częste pytania
Jakie nagłówki bezpieczeństwa powinna mieć każda strona?
Rozsądna baza: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy oraz ochrona przed osadzaniem w ramkach przez X-Frame-Options lub CSP frame-ancestors. API dodatkowo skorzysta na Cache-Control: no-store przy wrażliwych odpowiedziach.
Czy nagłówek X-XSS-Protection jest jeszcze potrzebny?
Nie. Nowoczesne przeglądarki usunęły audytor XSS, którym sterował, a w starych przeglądarkach nagłówek mógł wręcz wprowadzać podatności. Zamiast niego użyj rygorystycznego Content-Security-Policy.
Czy HSTS chroni już pierwszą wizytę?
Sam z siebie nie - przeglądarka poznaje regułę dopiero z pierwszej odpowiedzi HTTPS. Aby objąć ochroną pierwszą wizytę, zgłoś domenę na listę HSTS preload (hstspreload.org) i użyj dyrektywy preload razem z includeSubDomains.
Czy zły nagłówek może zepsuć moją stronę?
Tak, dwa klasyczne przypadki: zbyt rygorystyczne CSP blokuje Twoje własne skrypty lub style inline, a HSTS z includeSubDomains psuje każdą subdomenę działającą wciąż po czystym HTTP. CSP wdrażaj najpierw w trybie report-only, a HSTS zaczynaj od krótkiego max-age.
Śledź zmiany nagłówków na bieżąco
ePulz.io powiadomi cię, gdy nagłówek się zmieni (na przykład po wdrożeniu, które przez pomyłkę usunęło CSP).
Zacznij z ePulz.io →O tym narzędziu
Nagłówki bezpieczeństwa mówią przeglądarce, jak ma chronić Twoich odwiedzających. Ten audyt pokazuje, czy HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options i Referrer-Policy są rzeczywiście obecne, i ocenia wynik, dzięki czemu po wdrożeniu wychwycisz luki typu clickjacking czy MIME-sniffing.