Czym jest HSTS (HTTP Strict Transport Security)?

HTTP Strict Transport Security (HSTS) to mechanizm bezpieczeństwa, który instruuje przeglądarki, aby komunikowały się z Twoją witryną wyłącznie przez HTTPS. Gdy przeglądarka otrzyma nagłówek HSTS z Twojego serwera, automatycznie zamieni każde żądanie HTTP na HTTPS przez okres podany w nagłówku — nawet jeśli użytkownik wpisze http:// w pasku adresu lub kliknie stary link HTTP.

To może brzmieć jak drobne udogodnienie, ale rozwiązuje realny i niebezpieczny problem. Przyjrzyjmy się dokładnie, dlaczego HSTS istnieje, jak działa w praktyce i co musisz wiedzieć jako właściciel strony WordPress.

Jak działają ataki SSL stripping bez HSTS

Wyobraź sobie, że odwiedzający otwiera laptop w kawiarni i wpisuje twojastrona.pl w przeglądarce. Bez HSTS przeglądarka wysyła najpierw zwykłe żądanie HTTP do Twojego serwera. Serwer odpowiada przekierowaniem 301 do https://twojastrona.pl. Jednak to pierwsze żądanie HTTP jest całkowicie nieszyfrowane. Wędruje jako zwykły tekst przez sieć Wi-Fi kawiarni.

Atakujący w tej samej sieci może przechwycić to pierwsze nieszyfrowane żądanie techniką zwaną SSL stripping. Atakujący działa jako proxy: utrzymuje połączenie HTTPS z prawdziwym serwerem, ale serwuje ofierze wersję HTTP. Z perspektywy odwiedzającego strona wygląda normalnie (większość ludzi nie sprawdza kłódki). Tymczasem atakujący może czytać wszystko: dane logowania, treści formularzy, ciasteczka sesji i dane karty kredytowej.

To nie jest atak teoretyczny. Narzędzia takie jak sslstrip są publicznie dostępne od 2009 roku, a SSL stripping pozostaje jednym z najbardziej praktycznych ataków w publicznych sieciach Wi-Fi. HSTS jest zaprojektowany właśnie po to, by zamknąć tę lukę.

Jak HSTS chroni Twoją witrynę WordPress

Gdy Twój serwer wysyła następujący nagłówek odpowiedzi:

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

przeglądarka zapisuje tę instrukcję wewnętrznie. Przez kolejne 31 536 000 sekund (jeden rok) nigdy nie spróbuje nawiązać połączenia HTTP z Twoją domeną. Jeśli coś spróbuje wczytać zasób przez HTTP, przeglądarka przepisze to lokalnie na HTTPS, zanim żądanie w ogóle opuści urządzenie. Nie ma już nieszyfrowanego żądania, które atakujący mógłby przechwycić.

Ta ochrona działa na poziomie przeglądarki i to jest kluczowa zaleta. Nie jest potrzebne przekierowanie. Żadne nieszyfrowane żądanie nigdy nie jest wysyłane. Przeglądarka po prostu odmawia używania HTTP dla Twojej domeny.

Dyrektywy nagłówka HSTS

Nagłówek HSTS akceptuje trzy dyrektywy, a każda ma określone zastosowanie:

• max-age: czas w sekundach, przez który przeglądarka ma wymuszać HTTPS. Typowe wartości to 86400 (1 dzień, przydatne do początkowych testów), 2592000 (30 dni, rozsądny punkt startowy) oraz 31536000 (1 rok, zalecana wartość produkcyjna). Ustawienie zera natychmiast wyłącza wymuszanie HSTS dla Twojej domeny.
• includeSubDomains: rozszerza politykę HSTS na wszystkie subdomeny. Oznacza to, że cdn.twojastrona.pl, mail.twojastrona.pl i każda inna subdomena również będą zmuszone do HTTPS. Zachowaj ostrożność z tą dyrektywą: jeśli subdomena nie obsługuje HTTPS, stanie się niedostępna po jej aktywacji.
• preload: sygnał, że chcesz, aby Twoja domena trafiła na listy preload przeglądarek. Więcej o tym poniżej.

Problem pierwszej wizyty i listy preload HSTS

HSTS ma jedno fundamentalne ograniczenie: przeglądarka musi otrzymać nagłówek co najmniej raz, zanim zacznie cokolwiek wymuszać. Podczas pierwszej wizyty, zanim przeglądarka zobaczy Twój nagłówek HSTS, początkowe żądanie HTTP jest nadal podatne na przechwycenie. To znane jest jako "problem pierwszej wizyty" lub "bootstrap problem".

Lista preload HSTS rozwiązuje ten problem. To lista domen zakodowana bezpośrednio w przeglądarce (Chrome, Firefox, Safari i Edge używają tej samej listy). Jeśli Twoja domena znajduje się na liście preload, przeglądarka wymusza HTTPS od pierwszego połączenia, nawet jeśli użytkownik nigdy nie odwiedził Twojej strony.

Aby umieścić domenę na liście preload, musisz spełnić wszystkie wymagania:

• Dostarczać ważny certyfikat HTTPS na domenie głównej
• Przekierowywać cały ruch HTTP na HTTPS na tym samym hoście
• Wysyłać nagłówek HSTS na domenie głównej z max-age co najmniej 31536000 (jeden rok)
• Zawierać dyrektywę includeSubDomains
• Zawierać dyrektywę preload
• Wszystkie subdomeny muszą obsługiwać HTTPS

Możesz zgłosić swoją domenę na hstspreload.org. Pamiętaj, że umieszczenie na liście może zająć tygodnie lub miesiące (jest dystrybuowane wraz z aktualizacjami przeglądarek), a usunięcie jest równie powolne. Upewnij się, że konfiguracja HTTPS jest solidna, zanim zgłosisz domenę.

Typowe wartości max-age i zalecana strategia wdrażania

Kuszące jest od razu ustawienie max-age na rok, ale stopniowe wdrażanie jest bezpieczniejsze, zwłaszcza dla witryn z wieloma subdomenami lub złożoną konfiguracją:

• max-age=300 (5 minut): użyj podczas testów początkowych. Jeśli coś pójdzie nie tak, odwiedzający będą przywiązani do HTTPS tylko przez pięć minut.
• max-age=86400 (1 dzień): dobry kolejny krok po potwierdzeniu, że HTTPS działa poprawnie.
• max-age=2592000 (30 dni): przejdź tutaj po tygodniu lub dwóch stabilnego działania.
• max-age=31536000 (1 rok): zalecana wartość produkcyjna. To również minimum wymagane dla listy preload.

Konfiguracja HSTS w witrynie WordPress

WordPress sam nie wysyła nagłówka HSTS domyślnie. Masz kilka opcji, by go dodać:

Najbardziej niezawodnym podejściem jest dodanie nagłówka na poziomie serwera. W Apache dodaj poniższe do pliku .htaccess lub konfiguracji wirtualnego hosta:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Dla Nginx dodaj to w bloku server:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Jeśli nie masz dostępu do konfiguracji serwera (typowe w hostingach współdzielonych), możesz dodać nagłówek przez PHP w pliku functions.php motywu lub poprzez wtyczkę must-use:

add_action('send_headers', function() {
    header('Strict-Transport-Security: max-age=31536000; includeSubDomains; preload');
});

Podejście na poziomie serwera jest preferowane, ponieważ obejmuje wszystkie odpowiedzi, w tym pliki statyczne i strony błędów, a nie tylko strony generowane przez PHP.

Wiele wtyczek bezpieczeństwa WordPressa oferuje również konfigurację HSTS przez swoje panele ustawień, co może być wygodne, jeśli preferujesz podejście graficzne.

Typowe pułapki HSTS w WordPressie

Przed włączeniem HSTS sprawdź kilka rzeczy:

• Mixed content: upewnij się, że wszystkie zasoby (obrazy, skrypty, arkusze stylów, fonty) są ładowane przez HTTPS. HSTS wymusza główne połączenie na HTTPS, ale jeśli Twoja treść nadal odwołuje się do adresów HTTP, przeglądarki zablokują te zasoby.
• Odnawianie certyfikatu SSL: gdy HSTS jest aktywny, wygasły certyfikat sprawi, że Twoja strona stanie się całkowicie niedostępna (zamiast pokazać omijalne ostrzeżenie). Skonfiguruj automatyczne odnawianie certyfikatów z Let's Encrypt lub Twoim dostawcą.
• Gotowość subdomen: jeśli używasz includeSubDomains, każda subdomena musi mieć ważny certyfikat HTTPS. Subdomena staging na HTTP przestanie działać.
• Konfiguracja CDN: jeśli używasz CDN takiego jak Cloudflare, upewnij się, że HSTS jest skonfigurowany spójnie. Cloudflare oferuje własne ustawienia HSTS, które mogą nadpisywać nagłówki serwera.

Co sprawdza InspectWP

InspectWP analizuje, czy Twoja witryna WordPress wysyła nagłówek odpowiedzi Strict-Transport-Security. Raport ocenia wartość max-age, sprawdza dyrektywę includeSubDomains i sygnalizuje brak nagłówka, jeśli go nie ma. Poprawny nagłówek HSTS z długą wartością max-age (co najmniej sześć miesięcy lub jeden rok) i dyrektywą includeSubDomains jest zalecany dla każdej witryny WordPress działającej na HTTPS, co w dzisiejszym internecie powinno oznaczać każdą stronę.