Security

HTTP Headers

Wyświetl nagłówki odpowiedzi i audytuj polityki bezpieczeństwa.

URL http or https (default https). Up to 3 redirects are followed.

Try: github.com cloudflare.com example.com mozilla.org

O tym narzędziu

HTTP Headers pobiera Twój URL prawdziwym żądaniem HTTPS, przechwytuje każdy nagłówek odpowiedzi (oraz każdą pośrednią odpowiedź na trasie przekierowań) i przepuszcza wynik przez audyt bezpieczeństwa pokrywający nowoczesne nagłówki hardeningu: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options / CSP frame-ancestors, X-Content-Type-Options, Referrer-Policy i Permissions-Policy. Każdy nagłówek jest sprawdzany pod kątem obecności, sensowności wartości i luk względem best practices.

Poza audytem wymieniamy każdy nagłówek dosłownie, byś mógł potwierdzić politykę cache'owania (Cache-Control, ETag, Vary), śledzenie CDN (CF-Ray, X-Cache, X-Served-By), kompresję (Content-Encoding: br/gzip) i wszelkie własne nagłówki, które emituje Twój stack. Metoda HTTP (GET lub HEAD), negocjowana wersja HTTP (HTTP/1.1, HTTP/2, HTTP/3) i wersja TLS są raportowane w pasku żądania.

Kiedy używać tego narzędzia

Hardening bezpieczeństwa. Przed produkcją potwierdź, że HSTS, CSP i reszta są ustawione na bezpieczne wartości — minimum baseline Mozilla Observatory.
Debugowanie cache. Zobacz dokładnie, jakie Cache-Control i Vary emituje Twój CMS lub framework — częsta przyczyna "stara wersja się trzyma".
Audyty łańcuchów przekierowań. Wykryj przypadkowe łańcuchy 302-potem-301, pętle HTTP-do-HTTPS-do-innego-hosta i brakującą kanonizację.
Zachowanie CDN. Potwierdź, że Cloudflare/Fastly/CloudFront faktycznie cache'uje to, co myślisz, czytając nagłówki Age, X-Cache i specyficzne dla CDN.

Co pokrywa nasz audyt bezpieczeństwa

Dla każdego z sześciu nagłówków hardeningu raportujemy: obecny lub brakujący, rzeczywistą wartość i krótki werdykt ("good", "needs tightening", "vulnerable"). HSTS bez includeSubDomains, CSP z unsafe-inline lub Referrer-Policy pozostawiony na default są flagowane. Nigdy nie mówimy "idealnej" polityki, bo każda strona jest inna — ale mówimy, które pokrętła nadal są na ustawieniu fabrycznym.

Najczęstsze pytania

Co to jest HSTS i dlaczego ma znaczenie?

Strict-Transport-Security mówi przeglądarce "zawsze używaj HTTPS dla tej domeny, nawet jeśli użytkownik wpisał http:// lub kliknął link http://". Raz ustawione z rozsądnym max-age (typowo 31536000 = 1 rok), zapobiega atakom SSL-stripping przy kolejnych wizytach. Dodanie includeSubDomains rozszerza ochronę na każdą subdomenę — mocny default dla większości stron, ale upewnij się najpierw, że wszystkie naprawdę obsługują HTTPS.

Brakuje mi CSP — jak bardzo to niebezpieczne?

Bez CSP każda dziura XSS na Twojej stronie wykonuje się z pełną mocą: może wycieknąć ciasteczka, załadować skrypty kontrolowane przez atakującego lub przepisać DOM. Startowy CSP default-src 'self' blokuje najpopularniejsze ładunki XSS (inline skrypty, zewnętrzne ładowanie skryptów) niemal bezkosztowo. Bardziej restrykcyjne polityki zakazujące inline skryptów wymagają refaktoryzacji, ale dają znacznie silniejszą ochronę.

Czy podążacie za przekierowaniami?

Tak — do pięciu hopów. Każdy krok jest pokazany z metodą, statusem, location i nagłówkami, byś mógł wykryć hopy mieszanego protokołu (HTTP→HTTPS), brakującą kanonizację (apex vs www) lub przypadkowe pętle. Większość produkcyjnych stron powinna przekierowywać najwyżej raz (HTTP → HTTPS), a potem serwować zawartość; więcej niż dwa hopy to zwykle znak nakładających się reguł rewrite.

Dlaczego narzędzie pokazuje HTTP/2, choć skonfigurowałem HTTP/3?

HTTP/3 (QUIC nad UDP) wymaga od klienta opt-in poprzez nagłówek Alt-Svc przy pierwszym połączeniu. Nasz checker używa domyślnie HTTP/2 nad TCP, co wciąż robi większość klientów HTTP; jeśli Twój serwer ogłasza HTTP/3 w Alt-Svc, zobaczysz ten nagłówek w wyniku, ale sama odpowiedź pozostanie na HTTP/2. Obecność Alt-Svc to właściwa rzecz do sprawdzenia.