Nagłówek HTTP Strict Transport Security (HSTS) to fundamentalny mechanizm, który chroni strony internetowe przed obniżaniem poziomu protokołu i atakami typu man-in-the-middle. HSTS instruuje przeglądarki, aby zawsze używały wyłącznie szyfrowanych połączeń HTTPS, eliminując ryzyko wynikające z niezabezpieczonego HTTP. Mechanizm został zdefiniowany przez IETF w dokumencie RFC 6797 (listopad 2012) i stanowi kluczową warstwę ochrony nowoczesnych aplikacji webowych.
Definicja i fundamentalne koncepcje nagłówka HSTS
Czym jest HTTP Strict Transport Security
HTTP Strict Transport Security to polityka bezpieczeństwa, którą serwer komunikuje przeglądarce poprzez specjalny nagłówek odpowiedzi HTTP: Strict-Transport-Security. Zawarte w nim dyrektywy nakazują, by cała komunikacja z daną domeną odbywała się wyłącznie przez HTTPS (TLS/SSL). Kluczowe: HSTS działa po stronie przeglądarki – wymusza HTTPS niezależnie od intencji użytkownika. Nawet jeśli użytkownik wpisze adres w wersji HTTP, przeglądarka automatycznie przełączy żądanie na HTTPS.
HSTS rozwiązuje problem „pierwszego kontaktu” typowy dla przekierowań 301: przy samych przekierowaniach pierwsze żądanie leci przez HTTP, tworząc okno podatności. HSTS zamyka tę lukę, zapamiętując na określony czas wymóg HTTPS i automatycznie stosując go przy kolejnych wizytach.
Historia i standaryzacja HSTS
Impulsem do powstania HSTS był atak SSL-stripping zaprezentowany przez Moxie Marlinspike’a na Black Hat 2009, pokazujący łatwość konwersji HTTPS na HTTP w scenariuszu MITM. Społeczność bezpieczeństwa zaproponowała dedykowany nagłówek – ostatecznie zstandaryzowany jako RFC 6797.
Po wstępnym Internet Draft (czerwiec 2010) i kilku latach prac, specyfikację opublikowano w listopadzie 2012. Wspierają ją wszystkie główne przeglądarki: Chrome, Firefox, Opera, Safari, Internet Explorer 11 (Windows 10) oraz Microsoft Edge.
Mechanika działania HSTS i proces wymuszania HTTPS
Jak HSTS działa w praktyce
Po pierwszej wizycie przez HTTPS serwer może odesłać nagłówek Strict-Transport-Security. Przeglądarka zapisuje politykę na czas określony w max-age. Gdy użytkownik ponownie odwiedza domenę, przeglądarka sprawdza lokalny cache HSTS i – jeśli polityka obowiązuje – zanim wyśle jakiekolwiek żądanie zmienia schemat URL z HTTP na HTTPS. Konwersja następuje lokalnie w przeglądarce – bez wysyłania żądań HTTP.
Przykład: wpisanie http://example.com/ skutkuje natychmiastową zamianą na https://example.com/ przed jakąkolwiek komunikacją sieciową.
Struktura i komponenty nagłówka HSTS
Przykładowa, zalecana forma nagłówka wygląda następująco:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Dyrektywa max-age (w sekundach) jest obowiązkowa i określa czas obowiązywania polityki w przeglądarce. Przykładowo 31536000 sekund (1 rok). Licznik jest resetowany przy każdym ponownym otrzymaniu nagłówka.
Dyrektywa includeSubDomains rozszerza wymóg HTTPS na wszystkie subdomeny (np. api.example.com, mail.example.com, login.example.com). To krytycznie ważne, bo zabezpiecza również mniej oczywiste subdomeny.
Dyrektywa preload informuje o zgodzie na dopisanie domeny do globalnej listy preload HSTS. Domena na liście preload ma wymuszony HTTPS już przy pierwszej wizycie w dowolnej nowoczesnej przeglądarce.
Zagrożenia sieciowe, przed którymi chroni HSTS
SSL-stripping i ataki obniżające protokół
W ataku SSL-stripping napastnik pośredniczy między użytkownikiem a serwerem, konwertując ruch na HTTP i umożliwiając podsłuch oraz modyfikację. Użytkownik może nie zauważyć różnicy, a logowanie i dane wrażliwe stają się dostępne dla atakującego. HSTS uniemożliwia ten wektor, bo przeglądarka nigdy nie inicjuje połączeń HTTP dla objętej domeny.
Ataki man-in-the-middle i przechwytywanie sesji
MITM (np. przez ARP spoofing, podszycie pod router, złośliwe Wi‑Fi) pozwala przechwytywać i modyfikować niezabezpieczony ruch. Szczególnie groźne jest przejęcie cookie sesyjnych przesyłanych przez HTTP. HSTS minimalizuje ryzyko, wymuszając pełne szyfrowanie komunikacji.
Klikalne obejścia ostrzeżeń o certyfikatach
Bez HSTS użytkownicy często „klikają dalej” przy ostrzeżeniach o certyfikatach. To ułatwia MITM z fałszywym certyfikatem. HSTS zabrania obejścia błędów certyfikatu na chronionej domenie, blokując połączenie.
Konfiguracja HSTS na głównych serwerach internetowych
Konfiguracja na serwerze Apache
Do wysyłania nagłówka w Apache potrzebny jest moduł mod_headers. Podstawowa konfiguracja (np. w .htaccess) wygląda tak:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>
Aby ograniczyć wysyłkę wyłącznie do połączeń HTTPS, można użyć warunku środowiskowego:
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS
Zgodnie z RFC 6797 przeglądarki ignorują nagłówki HSTS dostarczone przez HTTP, ale warunek jest dobrą praktyką konfiguracyjną.
Konfiguracja na serwerze Nginx
W Nginx nagłówek definiuje się bezpośrednio w bloku server dla HTTPS (port 443):
server {
listen 443 ssl http2;
server_name example.com;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# pozostała konfiguracja SSL...
}
Opcja always gwarantuje dodanie nagłówka również przy odpowiedziach z kodami błędów.
Konfiguracja na serwerze IIS
W IIS nagłówek dodajemy w web.config:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />
</customHeaders>
</httpProtocol>
</system.webServer>
Dla Exchange Server można użyć PowerShell (podstawowe ustawienia HSTS):
$hstsElement = Get-IISConfigElement -ConfigElement $siteElement -ChildElementName "hsts"
Set-IISConfigAttributeValue -ConfigElement $hstsElement -AttributeName "enabled" -AttributeValue $true
Set-IISConfigAttributeValue -ConfigElement $hstsElement -AttributeName "max-age" -AttributeValue 31536000
Set-IISConfigAttributeValue -ConfigElement $hstsElement -AttributeName "includeSubDomains" -AttributeValue $true
Set-IISConfigAttributeValue -ConfigElement $hstsElement -AttributeName "preload" -AttributeValue $true
Dobre praktyki i rekomendowane wartości parametrów HSTS
Wybór odpowiednich wartości max-age
Parametr max-age równoważy bezpieczeństwo i elastyczność zarządzania. Rekomendowane jest stopniowe podnoszenie wartości zgodnie z poniższymi etapami:
- Test początkowy: 300 s (5 minut) – szybka walidacja bez ryzyka długotrwałej blokady.
- Faza obserwacji: 604800 s (1 tydzień) – monitoring logów i subdomen.
- Stabilizacja: 2592000 s (1 miesiąc) – dłuższe testy w ruchu produkcyjnym.
- Produkcja: 31536000 s (1 rok) – docelowo; dla preload często 63072000 s (2 lata).
Dyrektywa includeSubDomains
Włączenie includeSubDomains wymusza HTTPS na całej przestrzeni nazw. Przed aktywacją należy zinwentaryzować i przygotować wszystkie subdomeny (także wewnętrzne) do pracy przez TLS. Każda subdomena powinna wysyłać własny nagłówek HSTS, co ułatwia kontrolę i wzmacnia ochronę.
Dyrektywa preload i konsekwencje jej użycia
preload wiąże się z trwałym wpisem na listę HSTS preload przeglądarek. Zapewnia ochronę już przy pierwszej wizycie, ale wykreślenie z listy jest trudne i czasochłonne. Przed decyzją trzeba zapewnić ciągłość HTTPS (odnowienia certyfikatów, stabilną infrastrukturę TLS) i brak planów powrotu do HTTP.
Zaawansowane aspekty wdrażania HSTS
Pierwsza wizyta użytkownika i luka w bezpieczeństwie
HSTS nie chroni przy pierwszej wizycie – przeglądarka jeszcze nie zna polityki i może wykonać żądanie przez HTTP. Mechanizm preload niweluje tę lukę, ale nie każda domena może lub chce trafić na listę preload.
Zarządzanie certyfikatami SSL i ryzyka błędnej konfiguracji
Przy aktywnym HSTS przeglądarka nie pozwoli zignorować błędu certyfikatu (wygasły, samopodpisany itp.). Wygaśnięcie certyfikatu zablokuje dostęp wszystkim użytkownikom z zapisanym HSTS. Niezbędne są automatyzacja odnowień i stały monitoring.
Zbyt długa wartość max-age w połączeniu z błędem konfiguracji może zablokować dostęp na długi czas. Dlatego wdrażamy HSTS stopniowo.
Testowanie i weryfikacja konfiguracji HSTS
Aby szybko potwierdzić obecność nagłówka, użyj polecenia:
curl -I https://example.com | grep -i strict-transport-security
Przydatne serwisy do analizy konfiguracji HTTPS i nagłówków bezpieczeństwa to:
- Qualys SSL Labs – pełny audyt konfiguracji TLS/SSL, ocena i rekomendacje;
- Security Headers – kontrola i scoring nagłówków bezpieczeństwa;
- Rakkotools – szybkie testy HSTS, CSP i powiązanych ustawień.
W Chrome/Edge status HSTS można sprawdzić pod adresami: chrome://net-internals/#hsts, edge://net-internals/#hsts (sekcja „Query domain HSTS/PKP status”).
HSTS preload – dodatkowa warstwa ochrony
Czym jest HSTS preload
HSTS preload to wbudowana w przeglądarki lista domen, dla których zawsze wymuszany jest HTTPS. Listę utrzymuje Google i dystrybuuje do Chrome, Firefox, Safari, Opera i Edge. Eliminuje to ryzyko „trust on first use”.
Wymagania dla HSTS preload
Aby dodać domenę do listy, muszą być spełnione następujące warunki nagłówka HSTS:
- max-age – co najmniej 31536000 s (zalecane 63072000 s);
- includeSubDomains – dyrektywa włączona;
- preload – dyrektywa włączona.
Dodatkowo domena musi mieć ważny certyfikat TLS i być dostępna przez HTTPS (również bez www). Jeśli główna domena przekierowuje do www, obie powinny wysyłać nagłówek HSTS.
Proces dodania do listy preload
Zgłoszenia dokonuje się na stronie https://hstspreload.org/: po weryfikacji wymagań można wysłać domenę do akceptacji. Po zatwierdzeniu trafia ona do następnych aktualizacji list w przeglądarkach (zwykle kilka tygodni do kilku miesięcy do pełnej propagacji).
Problemy i ograniczenia HSTS
„Zaufaj za pierwszym razem” – fundamentalne ograniczenie
Domeny nieobjęte preloadem pozostają podatne przy pierwszej wizycie (TOFU). Potencjalne alternatywy (np. DNSSEC) mają ograniczenia wdrożeniowe; dziś preload jest praktycznie najlepszą metodą redukcji tego ryzyka.
Błędy konfiguracji i ich konsekwencje
Długi max-age przy niepełnym wsparciu HTTPS może spowodować długotrwałą blokadę użytkowników. Włączenie preload bez pełnej gotowości jest szczególnie ryzykowne, a usuwanie z listy trwa miesiącami.
Problemy z mieszaną zawartością
Mixed content (ładowanie zasobów przez HTTP na stronie HTTPS) bywa blokowany przez przeglądarki, zwłaszcza dla skryptów i CSS. HSTS nie naprawia odnośników – linki należy zaktualizować do HTTPS, a dostawcy zewnętrzni muszą również wspierać TLS.
Zgodność przeglądarek i wsparcie użytkowników
Przeglądarki wspierające HSTS
Lista szeroko wspieranych przeglądarek obejmuje:
- Firefox – od wersji 4;
- Chrome – od wersji 4;
- Opera – od wersji 12;
- Safari – od wersji 7;
- Internet Explorer 11 – w Windows 10;
- Microsoft Edge – wszystkie wspierane wersje.
Starsze przeglądarki (np. IE < 11) nie obsługują HSTS i są wycofywane.
Strategie dla starszych przeglądarek
Aby zwiększyć bezpieczeństwo w środowiskach bez wsparcia HSTS, zastosuj komplementarne środki:
- 301 z HTTP do HTTPS – uniwersalne przekierowanie dla wszystkich przeglądarek;
- Content-Security-Policy – dyrektywy
upgrade-insecure-requestsiblock-all-mixed-contentograniczają mieszane treści; - Dodatkowe nagłówki – np.
X-Frame-Options,X-Content-Type-Options,Referrer-Policywzmacniają ogólną odporność.
Praktyczne wdrażanie HSTS w organizacjach
Planowanie wdrażania
Przygotuj plan: audyt wszystkich subdomen, ocena gotowości do HTTPS, testy na środowisku staging i stopniowe wdrożenie w produkcji. Ustaw automatyczne odnowienia certyfikatów i alerty przed ich wygaśnięciem.
Monitorowanie po wdrożeniu
Monitoruj ciągłość wysyłania nagłówka, ważność certyfikatów i błędy po stronie użytkowników. Narzędzia takie jak SecurityScorecard potrafią automatycznie obserwować konfigurację HSTS w domenie i subdomenach.