Czym są flagi bezpieczeństwa cookies?

Za każdym razem, gdy Twoja witryna WordPress ustawia cookie — czy to dla sesji logowania, koszyków zakupowych, analityki czy preferencji zgody — to cookie może mieć zestaw flag bezpieczeństwa. Te flagi mówią przeglądarce, jak obchodzić się z cookie: kiedy je wysyłać, kto może je czytać i przez jakie połączenia może podróżować. Ich błędne ustawienie nie powoduje widocznych problemów, ale otwiera drzwi do ataków, które większość właścicieli witryn zauważa dopiero, gdy jest za późno.

Flaga Secure

Cookie z flagą Secure jest wysyłane tylko przez połączenia HTTPS. Przeglądarka po prostu odmawia dołączenia go do nieszyfrowanych żądań HTTP.

Set-Cookie: session_id=abc123; Secure

Dlaczego ma to znaczenie? Wyobraź sobie odwiedzającego, który korzysta z Twojej witryny w wifi w kawiarni. Jeśli przypadkiem załaduje stronę przez zwykłe HTTP — np. ze starej zakładki lub złej konfiguracji przekierowania — cookies normalnie podróżowałyby przez sieć w postaci tekstu jawnego. Każdy, kto podsłuchuje ruch w tej sieci wifi, może przechwycić cookie sesji i podszyć się pod użytkownika. Z flagą Secure przeglądarka całkowicie wstrzymuje cookie w tym scenariuszu.

Ponieważ Twoja witryna WordPress i tak powinna działać na HTTPS (i musi — w 2025 roku nie ma już wymówek), ustawienie tej flagi nic nie kosztuje i zapobiega realnej klasie ataków.

Flaga HttpOnly

Flaga HttpOnly uniemożliwia JavaScript dostęp do cookie poprzez document.cookie. Cookie wciąż jest normalnie wysyłane z żądaniami HTTP, ale żaden skrypt po stronie klienta nie może go odczytać ani zmodyfikować.

Set-Cookie: session_id=abc123; HttpOnly

Ta flaga istnieje specjalnie po to, by ograniczyć szkody wynikające z ataków Cross-Site Scripting (XSS). Jeśli atakującemu uda się wstrzyknąć JavaScript do Twojej strony — przez podatną wtyczkę, pole komentarza lub zapisany wektor XSS — jedną z pierwszych rzeczy, jakie spróbuje zrobić skrypt, jest sięgnięcie do document.cookie w celu kradzieży tokenów sesji. Z włączonym HttpOnly to wywołanie nie zwraca nic dla chronionych cookies.

Nie zapobiega to samemu XSS. Nie naprawia podstawowej luki. Ale zdejmuje ze stołu najcenniejszą nagrodę — cookies sesji — co często stanowi różnicę między uciążliwością a pełnym przejęciem konta.

Flaga SameSite

Atrybut SameSite kontroluje zachowanie cookie w kontekstach cross-site. Określa, czy przeglądarka wyśle cookie, gdy żądanie pochodzi z innej domeny niż ta, która ustawiła cookie.

Istnieją trzy możliwe wartości:

• SameSite=Strict — Cookie nigdy nie jest wysyłane przy żądaniach cross-site. Kropka. Jeśli ktoś kliknie link do Twojej witryny z zewnętrznej strony, cookie sesji nie zostanie dołączone do tego początkowego żądania. To najbardziej restrykcyjne ustawienie i może powodować problemy z użytecznością (użytkownicy wyglądają, jakby byli wylogowani, gdy przychodzą przez zewnętrzne linki).
• SameSite=Lax — Cookie jest wysyłane przy nawigacjach na poziomie najwyższym (kliknięcie linku), ale nie przy żądaniach osadzonych, takich jak obrazy, iframe czy wysyłanie formularzy z innych witryn. To domyślne ustawienie przeglądarek od Chrome 80 (2020) i oferuje dobrą równowagę między bezpieczeństwem a użytecznością.
• SameSite=None — Cookie jest wysyłane przy wszystkich żądaniach, niezależnie od pochodzenia. Jest to potrzebne dla uzasadnionych zastosowań third-party cookies (osadzone formularze płatności, SSO, reklamy), ale musi być zawsze łączone z flagą Secure — przeglądarki odrzucają SameSite=None bez Secure.

Set-Cookie: session_id=abc123; SameSite=Lax

Głównym zagrożeniem, któremu przeciwdziała SameSite, jest Cross-Site Request Forgery (CSRF) — ataki, w których złośliwa witryna nakłania Twoją przeglądarkę do wykonywania uwierzytelnionych żądań do Twojej witryny WordPress bez Twojej wiedzy.

Wszystko razem

Dla cookies uwierzytelniania i sesji rekomendowana konfiguracja to:

Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Lax; Path=/

Każda flaga pokrywa inny wektor ataku:

• Secure — zapobiega przechwyceniu na poziomie sieci
• HttpOnly — zapobiega kradzieży na poziomie skryptu (XSS)
• SameSite — zapobiega nadużyciom cross-origin (CSRF)

Brak którejkolwiek pozostawia lukę. Działają jako zespół.

A co z third-party cookies?

Cookies ustawiane przez zewnętrzne usługi ładowane na Twojej witrynie (analityka, widgety czatu, piksele reklamowe) nie są pod Twoją bezpośrednią kontrolą. Ich flagi bezpieczeństwa są określane przez usługę, która je ustawia. Ale musisz być ich świadomy — third-party cookie bez Secure lub z SameSite=None tworzy ekspozycję na Twojej domenie, mimo że to nie Ty go ustawiłeś.

Jest to szczególnie istotne w kontekście zgodności z GDPR: wiedza, jakie cookies są ustawiane na Twojej witrynie i jak są skonfigurowane, jest częścią Twojej odpowiedzialności jako operatora witryny.

Jak InspectWP pomaga

InspectWP analizuje każde cookie ustawione podczas ładowania strony Twojej witryny WordPress i oznacza te, którym brakuje atrybutów Secure, HttpOnly lub SameSite. Raport pokazuje każde cookie wraz z jego aktualnymi flagami, dzięki czemu szybko widzisz, które wymagają uwagi — niezależnie od tego, czy pochodzą z rdzenia WordPress, wtyczek czy skryptów firm trzecich.