Jak ustawić HSTS

Wdrożenie HSTS to prosty, a zarazem potężny sposób na wymuszenie połączeń po HTTPS i uszczelnienie warstwy transportowej Twojej witryny. Poniżej znajdziesz praktyczną instrukcję krok po kroku: od planu działań, przez poprawną konfiguracja na popularnych serwerach, po testy i utrzymanie. Pokażę też, jak bezpiecznie dodać właściwe nagłówki, uniknąć pułapek i przygotować się do pracy z subdomenami, CDN oraz automatyzacją, aby realnie podnieść bezpieczeństwo usługi.

Co to jest HSTS i jak działa

Istota mechanizmu

HTTP Strict Transport Security to polityka bezpieczeństwa, którą serwer ogłasza przeglądarce za pomocą nagłówka Strict-Transport-Security. Po jej otrzymaniu przeglądarka zapamiętuje domenę jako „HTTPS only” na określony czas i automatycznie wymusza użycie szyfrowanego protokołu nawet wtedy, gdy użytkownik wpisze adres z http:// lub kliknie niepoprawny link. Dzięki temu znika ryzyko ataków typu downgrading (przełączenie na nieszyfrowany protokół) oraz przechwytywania sesji na pierwszym zapytaniu.

Parametry kluczowe

Politykę definiują trzy główne komponenty:

• max-age – czas (w sekundach), przez jaki przeglądarka ma wymuszać protokół. Przykład: 31536000 (rok).
• includeSubDomains – rozszerza politykę na wszystkie subdomeny.
• preload – sygnalizuje chęć dopisania domeny do listy HSTS w przeglądarkach (tzw. HSTS preload list), co wymusza HTTPS nawet przed pierwszym połączeniem.

Korzyści i ograniczenia

Największym atutem HSTS jest eliminacja „pierwszego nieszyfrowanego kontaktu” oraz ochrona użytkowników przed manipulacją ruchem. Ograniczenia wynikają głównie z nieodwracalności niektórych decyzji (np. aktywacja includeSubDomains i wysoki max-age) oraz z tego, że raz ustawiona polityka może zablokować dostęp do usług, które nie są dostępne po HTTPS. Dlatego przed wdrożeniem trzeba wykonać inwentaryzację i testy.

Najczęstsze pułapki

• Włączenie HSTS przy niepełnym pokryciu subdomen certyfikatami lub usługami HTTPS.
• Zbyt długie max-age już na starcie – utrudnia szybkie wycofanie w razie błędu.
• Aktywacja polityki na środowisku, gdzie działają usługi legacy, linkujące do http:// zasobów.
• Niewłaściwe kolejności mechanizmów – brak globalnych przekierowania http→https lub mieszane treści w HTML/CSS/JS.

Plan działania przed włączeniem HSTS

Inwentaryzacja domen i subdomen

Zbierz listę wszystkich domen i subdomen serwowanych z Twojej infrastruktury. Odpowiedz na pytania:

• Które hosty serwują treści webowe (HTTP/HTTPS), a które pełnią inne role (np. API, zasoby statyczne, panele admina)?
• Czy każda z tych nazw ma ważny certyfikat TLS obejmujący właściwy FQDN (lub wildcard)?
• Czy istnieją hosty, które z różnych powodów nie mogą (jeszcze) działać po HTTPS?

Certyfikaty, łańcuchy zaufania i TLS

Zweryfikuj:

• Aktualność i poprawność certyfikatów – czy nie wygasają w krótkim terminie, czy zawierają właściwe SANy.
• Łańcuch pośredni (intermediate) – zła konfiguracja może skutkować błędami w części przeglądarek.
• Wymuszenie aktualnych protokołów (TLS 1.2/1.3) i bezpiecznych szyfrów.

Globalne przekierowania http→https

Upewnij się, że każde żądanie po http:// jest niezwłocznie kierowane do https://. Dobre praktyki:

• Przekierowanie 301 na poziomie frontowego serwera (reverse proxy) lub wirtualnego hosta HTTP.
• Brak zbędnych hopów – z http://example.com do https://example.com bez pośrednich adresów.
• Spójna kanonizacja (www vs bez www) – podejmij decyzję i stosuj ją konsekwentnie.

Usuwanie treści mieszanych (mixed content)

Włącz HSTS dopiero, gdy wszystkie zasoby w dokumencie (obrazy, skrypty, style, fonty, XHR) ładują się po HTTPS. Sprawdź:

• Linki absolutne w HTML i CSS (http://… → https://… lub protokołowo względne //…)
• Adresy w konfiguracji aplikacji i zmiennych środowiskowych.
• Zasoby zewnętrzne (mapy, wideo, biblioteki) – czy dostawcy wspierają HTTPS.

Analiza wpływu na subdomeny

Jeśli planujesz includeSubDomains, potwierdź, że każda subdomena obsługująca HTTP ma działający HTTPS. W przeciwnym razie narazisz użytkowników na błędy blokujące. Uwaga na hosty legacy, panele administracyjne, narzędzia deweloperskie i wewnętrzne portale.

Konfiguracja na popularnych serwerach

Apache HTTP Server (httpd)

Włącz moduł odpowiedzialny za nagłówki i dodaj politykę w vhoście HTTPS:

• Aktywuj moduł: a2enmod headers (Debian/Ubuntu) lub sprawdź LoadModule headers_module.
• W vhost dla portu 443 dodaj dyrektywę ustawiającą HSTS, np.: Header always set Strict-Transport-Security: max-age=31536000; includeSubDomains
• Jeśli testujesz, zacznij od krótszego czasu, np. 300 lub 86400.
• Po zmianach przeprowadź graceful reload i sprawdź odpowiedzi HEAD.

Dobre praktyki:

• Ustawiaj nagłówek wyłącznie w vhoście HTTPS, aby uniknąć przypadkowego dodania na HTTP.
• Nie doklejaj polityki w .htaccess, jeśli nie musisz – lepsza jest centralna konfiguracja vhosta.

Nginx

Dodaj dyrektywę do sekcji serwera na 443:

• add_header Strict-Transport-Security „max-age=31536000; includeSubDomains” always;
• Rozważ etap testów z krótszym max-age, a dopiero później zwiększ do roku lub dłużej.
• Upewnij się, że blok serwera dla portu 80 zawiera przekierowanie 301 na https.

W środowiskach z wieloma serwerami backend pamiętaj, że tylko front (Nginx) powinien doklejać politykę.

Microsoft IIS

Możesz użyć IIS Manager lub web.config:

• W GUI: HTTP Response Headers → Add → Name: Strict-Transport-Security → Value: max-age=31536000; includeSubDomains
• W web.config: sekcja system.webServer → httpProtocol → customHeaders → add.
• Zastosuj reguły URL Rewrite, aby wymusić przekierowanie http→https.

Node.js (Express)

Jeśli aplikacja korzysta z Express, użyj biblioteki helmet lub ustaw nagłówek ręcznie:

• helmet.hsts({ maxAge: 31536000 * 1000, includeSubDomains: true })
• Lub: res.set(„Strict-Transport-Security”, „max-age=31536000; includeSubDomains”)
• Upewnij się, że aplikacja działa za reverse proxy z poprawnym terminowaniem TLS.

Tomcat / Java

Dodaj filtr serwletów ustawiający nagłówek w odpowiedzi lub skonfiguruj serwer frontowy (Nginx/Apache) jako reverse proxy i tam doklejaj politykę. W środowiskach korporacyjnych to drugie podejście bywa prostsze w utrzymaniu i audycie.

Reverse proxy, load balancery i CDN

Najczęściej polityka powinna być dodawana na brzegu – w punkcie terminowania TLS.

• HAProxy: http-response set-header Strict-Transport-Security max-age=31536000; includeSubDomains
• Cloudflare: w Zarządzaniu nagłówkami/Transform Rules ustaw HSTS lub włącz „HSTS” w panelu z odpowiednimi parametrami.
• AWS CloudFront/ALB: użyj funkcji ustawiania nagłówków w Behaviors/Rules lub Lambda@Edge.

Upewnij się, że żaden backend nie nadpisuje nagłówka inną, sprzeczną wartością.

Testowanie, wdrażanie i wycofywanie

Strategia bezpiecznego startu

Wdrażaj etapami:

• Etap 1: krótki max-age (np. 300–3600 sekund) na ograniczonym ruchu lub tylko na wybranej domenie testowej.
• Etap 2: 1 dzień – sprawdź logi błędów, analitykę, sygnały z helpdesku.
• Etap 3: 1–4 tygodnie – równolegle audyt subdomen i automatyczne testy e2e.
• Etap 4: 6–12 miesięcy po pełnej weryfikacji.

Weryfikacja nagłówka

Sprawdź odpowiedzi HTTP z produkcji i preprodukcji:

• curl -I https://twojadomena.pl – nagłówek Strict-Transport-Security powinien być widoczny tylko na HTTPS.
• curl -I http://twojadomena.pl – brak HSTS; powinno zwrócić 301 do https.
• Dla subdomen – powtórz testy, jeśli planujesz includeSubDomains.

Kontrola w przeglądarce

Użyj narzędzi developerskich (Network) i sprawdź, czy kolejne wizyty przechodzą automatycznie na HTTPS. W Chrome można podejrzeć stan polityki w chrome://net-internals/#hsts (w nowszych wersjach strona pomocy może być inna – poszukaj HSTS w ustawieniach deweloperskich).

Monitoring i alertowanie

Dodaj metryki i testy syntetyczne:

• Kontrola obecności nagłówka i poprawnego przekierowania z HTTP.
• Skrypty wykrywające mixed content na krytycznych ścieżkach.
• Alerty, gdy host nie obsługuje już HTTPS lub certyfikat wygasa.

Wycofywanie zmian (roll-back)

Jeżeli musisz wycofać HSTS (np. błąd w subdomenach):

• Ustaw politykę z max-age=0 (lub bardzo niską wartością), bez includeSubDomains i bez preload.
• Utrzymaj tę odpowiedź aż do czasu, gdy większość klientów odświeży politykę.
• Pamiętaj: jeśli domena trafiła do listy preload, wycofanie wymaga procesu zdjęcia z tej listy i może potrwać tygodnie/miesiące.

Scenariusze specjalne

• Środowiska staging: nie dodawaj do preload, utrzymuj krótki max-age.
• Aplikacje mobilne: biblioteki HTTP zwykle nie respektują HSTS jak przeglądarki – testuj zachowanie klientów natywnych.
• SSO i logowanie przez zewnętrznych dostawców: upewnij się, że wszystkie URL-e callbacków są na HTTPS.

Preload, utrzymanie i dobre praktyki

Kryteria wejścia na listę preload

Aby zgłosić domenę do preload, musisz spełnić warunki:

• Serwować HSTS na domenie głównej i wszystkich przekierowaniach.
• Użyć parametrów: max-age co najmniej 31536000 oraz includeSubDomains i flaga preload w polityce.
• Zapewnić poprawne certyfikaty i bezbłędne przekierowania na całej ścieżce.

Zanim to zrobisz, wykonaj pełen audyt subdomen – błąd może zablokować ważne usługi.

Zgłoszenie i weryfikacja

Wejdź na serwis zarządzający listą HSTS preload (oficjalna strona projektu przeglądarek) i przejdź przez kreator:

• Zweryfikuj domenę, wklej nagłówek z produkcji i uruchom testy.
• Po pozytywnej walidacji złóż wniosek i śledź status PR/zgłoszenia.
• Miej świadomość: publikacja w stabilnych wersjach przeglądarek może zająć tygodnie.

Utrzymanie polityki w cyklu życia

• Automatyzuj odświeżanie certyfikatów (ACME/Let’s Encrypt) i testuj je w pipeline CI/CD.
• Dodaj testy kontraktowe sprawdzające obecność i poprawność HSTS.
• Waliduj, że polityka nie jest dublowana lub sprzeczna między warstwami (app, proxy, CDN).
• Regularnie skanuj subdomeny w poszukiwaniu hostów bez HTTPS.

Integracje z innymi kontrolami

HSTS najlepiej działa w parze z:

• Content Security Policy (CSP) – zapobiega wstrzyknięciom i ogranicza źródła zasobów.
• HTTP/2 i HTTP/3 – wydajniejsze protokoły na warstwie TLS.
• SameSite/secure dla ciasteczek – wymuszenie secure flag minimalizuje ryzyko wycieku połączeniem nieszyfrowanym.

Checklista wdrożeniowa krok po kroku

• Spisz wszystkie domeny i subdomeny; oceń gotowość na HTTPS.
• Zapewnij poprawne certyfikaty i konfigurację TLS.
• Włącz 301 z HTTP do HTTPS na brzegu infrastruktury.
• Usuń mixed content i ustaw secure/SameSite dla cookies.
• Dodaj HSTS z krótkim max-age i przetestuj kluczowe ścieżki.
• Monitoruj błędy, popraw regresje, wydłuż max-age.
• Po pełnej weryfikacji rozważ includeSubDomains.
• Jeśli spełniasz warunki i rozumiesz konsekwencje – zgłoś domenę do preload.

Przykłady polityk w zależności od etapu

Start (tryb ostrożny):

• Strict-Transport-Security: max-age=300

Stabilizacja:

• Strict-Transport-Security: max-age=86400

Produkcja dojrzała:

• Strict-Transport-Security: max-age=31536000; includeSubDomains

Gotowość do listy preload (tylko po pełnej weryfikacji):

• Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Rozwiązywanie problemów

• Po aktualizacji brak HSTS: sprawdź, czy nagłówek nie został usunięty na innej warstwie.
• Błędy certyfikatów na subdomenach: rozważ wildcard lub automatyzację wydawania SAN.
• Użytkownicy raportują blokadę dostępu: obniż tymczasowo max-age do 0, sprawdź ścieżkę pośrednich przekierowań i certyfikatów.
• CDN zmienia odpowiedzi: wyłącz nadpisywanie nagłówków w regułach cache/edge lub ustaw je explicite na brzegu.

Aspekty organizacyjne i zgodności

• Polityka bezpieczeństwa firmy: wpisz HSTS do standardów wdrożeniowych dla usług publicznych.
• Audyt i logi: rejestruj brak HSTS lub niespójności jako alerty jakościowe.
• Komunikacja zmian: poinformuj zespoły aplikacyjne o konsekwencjach includeSubDomains i ewentualnego wejścia na listę preload.

Często zadawane pytania

• Czy HSTS dotyczy poczty i FTP? – Nie, działa dla HTTP/HTTPS; nie wpływa na inne protokoły.
• Czy muszę mieć EV/OV certyfikat? – Nie, ważny jest certyfikat zaufany przez przeglądarki, niezależnie od typu.
• Czy HSTS spowolni stronę? – Nie; to jeden nagłówek i mechanizm przeglądarki; często przyspiesza, eliminując zbędne przekierowania.
• Co jeśli klient używa bardzo starej przeglądarki? – Mechanizm może nie być wspierany; nadal jednak korzyści obejmą większość użytkowników.