LW IT Solutions logo LW IT Solutions logo LW IT Solutions
« Przegląd bloga /Data Privacy/Tutorials / Secure, HttpOnly, SameSite: co dwadzieścia stron głównych...
Ten artykuł w innych językach:

Secure, HttpOnly, SameSite: co dwadzieścia stron głównych dodaje do swoich ciasteczek

Secure, HttpOnly, SameSite: co dwadzieścia stron głównych dodaje do swoich ciasteczek
Spis treści
  1. Trzy słowa, trzy różne zagrożenia
  2. Co zmierzono
  3. Dwanaście z dwudziestu nie ustawia nic
  4. Secure to reguła, HttpOnly wyjątek
  5. Trzy przypadki z osobna
  6. Ile naprawdę kosztuje brak HttpOnly
  7. Pytania i odpowiedzi
  8. Źródła

Ciasteczko to krótka linijka, którą serwer daje przeglądarce do zapamiętania i odesłania. Można do niej dopisać trzy nieobowiązkowe atrybuty, z których każdy chroni przed innym zagrożeniem.

Dopisanie ich nic nie kosztuje. Zmierzone na dwudziestu dużych stronach głównych: dwa z trzech są rozpowszechnione, a trzeciego brakuje częściej, niż jest – i właśnie na nim zależy wtedy, gdy coś już poszło źle.

Dwanaście z dwudziestu stron głównych nie ustawia ciasteczka, dwadzieścia dziewięć ciasteczek na pozostałych, i w skali ile z nich niesie Secure, SameSite oraz HttpOnly
Z 29 ciasteczek 23 niosły słowo Secure, 17 SameSite, a 12 HttpOnly.

Trzy słowa, trzy różne zagrożenia

Secure znaczy: ciasteczko podróżuje wyłącznie przez połączenie szyfrowane. Bez tego słowa wystarczy jedno zapytanie zwykłym HTTP – przekręcony adres, stara zakładka, odnośnik w wiadomości – i wartość leży otworem dla każdego w tej samej sieci.

HttpOnly znaczy: skrypty w przeglądarce nie mogą odczytać ciasteczka. To słowo istnieje na wypadek, gdy na stronie działa kod, którego nikt tam nie chciał: wstrzyknięty skrypt, przejęta obca biblioteka, kiepska reklama. Bez tego słowa taki kod odczyta ciasteczko sesji jedną linijką.

SameSite reguluje, czy ciasteczko jedzie razem z zapytaniem przychodzącym z innej witryny. To obrona przed ukrytym formularzem na obcej stronie, które wykonuje czynność w imieniu tego, kto akurat jest zalogowany.

Troje drzwi, a żadne z trzech nie pomaga przy tym, czego pilnują pozostałe dwa.

Co zmierzono

Dwadzieścia dużych stron głównych otwarto 2 września 2026 po jednym razie. Podążano za przekierowaniami, ale niczego nie akceptowano ani nie klikano. Wszystkie dwadzieścia odpowiedziały statusem 200.

Liczono każdą linijkę Set-Cookie dokładnie taką, jaka przyszła: ciasteczka ustawiane przed jakąkolwiek zgodą – czyli dokładnie ten zestaw, który wizyta zbiera, nie robiąc niczego.

Co dokłada potem baner zgody, jest osobnym pytaniem i liczbą znacznie większą. To jest podłoga, nie sufit.

Dwanaście z dwudziestu nie ustawia nic

Największa pojedyncza grupa w pomiarze nie ustawia przy pierwszej wizycie żadnego ciasteczka: dwanaście z dwudziestu.

To w większości strony projektów i dokumentacji – ten rodzaj strony, który pokazuje tekst i nie ma czego pamiętać. Trzeba to powiedzieć wyraźnie, bo flagi stają się pytaniem dopiero po decyzji o ustawieniu ciasteczka, a ta decyzja odpada częściej, niż używane jest którekolwiek z trzech słów.

Pozostałe osiem stron ustawia razem 29 ciasteczek, od jednego aż po dziesięć na jednej stronie.

Rząd małych pojemników z pieczęciami na wiekach; jeden stoi otwarty, jego wieko leży obok

Secure to reguła, HttpOnly wyjątek

Z tych 29 ciasteczek 23 niosły słowo Secure, 17 słowo SameSite, a 12 słowo HttpOnly.

Ta kolejność nie jest przypadkiem. Secure jedzie dziś prawie samo z siebie: przeglądarki naciskają na to od lat, a zestawy narzędzi ustawiają je domyślnie na stronie szyfrowanej. SameSite przyszło z wartością domyślną, więc ciasteczko bez tego słowa traktuje się tak, jakby zażądało ustawienia środkowego – słowa często brak, ochrony nie.

HttpOnly takiej wartości domyślnej nie ma. Ciasteczko bez tego słowa jest czytelne dla każdego skryptu na stronie, a nic nie dopisze go za nikogo.

Trzy przypadki z osobna

Wikipedia ustawiła najwięcej i pilnowała ich najlepiej: dziesięć ciasteczek, każde Secure, sześć z nich HttpOnly. Tylko cztery niosły SameSite, co dokładnie pasuje do wzoru powyżej.

New York Times ustawił dziewięć i ani jedno nie było HttpOnly. Pięć było Secure, pięć niosło SameSite – zabezpieczenia przed ciasteczkiem idącym złą drogą były więc częściowo na miejscu, a to przed czytającym skryptem brakowało zupełnie.

A dwie strony ustawiły po jednym ciasteczku bez żadnego z trzech słów: apple.com i php.net. Po jednym ciasteczku, bez wymogu szyfrowania, czytelne dla każdego skryptu, wysyłane skądkolwiek.

Ile naprawdę kosztuje brak HttpOnly

Trzech słów nie da się zastąpić równie dobrze.

Bez Secure ciasteczko wycieka przy zapytaniu nieszyfrowanym – a na stronie, która wszystko przekierowuje na HTTPS i wysyła surowy nagłówek transportu, takie zapytanie w zasadzie nie występuje.

Bez SameSite działa ustawienie domyślne przeglądarki, które najgorszy przypadek odpiera samo.

Bez HttpOnly nie wkracza nic. Ciasteczko jest czytelne dla każdego kodu działającego na stronie, a to, że na stronie działa obcy kod, nie jest rzadkim zdarzeniem: to zwyczajny skutek przejęcia gdzieś daleko jednego wpiętego obcego skryptu.

Dlatego zmierzona tutaj kolejność biegnie na opak. Słowo dopisywane najrzadziej jest tym, za które nic innego nie wskakuje.

Pytania i odpowiedzi

Czy każde ciasteczko da się ustawić z HttpOnly?

Nie. HttpOnly oznacza, że żaden skrypt nie odczyta ciasteczka, a to wyklucza każde ciasteczko istniejące dla skryptu: stan zgody, który skrypt banera musi odczytać przy następnym wyświetleniu strony, albo identyfikator, który narzędzie analityczne samo zapisuje i odczytuje w przeglądarce.

Skrypt nie może w ogóle ustawić HttpOnly. Ciasteczka, które tworzy przez document.cookie, nie są ustawiane za pomocą nagłówka. Nie pojawiają się więc w żadnej linijce Set-Cookie i nie zostały policzone w artykule; w ich przypadku pytanie o ten atrybut się nie pojawia.

Ze wszystkim, czego potrzebuje tylko serwer, jest odwrotnie: ciasteczek sesji i logowania nie czyta żaden skrypt, więc nie ma powodu rezygnować u nich z HttpOnly. Przydatna reguła brzmi zatem: to, co ustawia serwer i czego nie czyta żaden skrypt strony, dostaje HttpOnly.

Czy strona z ciasteczkiem sesji HttpOnly jest bezpieczna wobec wstrzykniętego skryptu?

Tylko częściowo. HttpOnly nie pozwala skryptowi odczytać wartości i wynieść jej, żeby później używać sesji gdzie indziej. Nie powstrzymuje jednak skryptu przed działaniem wewnątrz strony: do zapytań, które skrypt stamtąd wysyła, przeglądarka automatycznie dołącza ciasteczko, więc może on zrobić wszystko, co zalogowanej osobie akurat wolno, dopóki strona jest otwarta.

HttpOnly ogranicza więc szkody, zamiast im zapobiegać. Przeciw samemu wstrzykniętemu skryptowi działają inne środki, na przykład Content Security Policy określająca, skąd mogą pochodzić skrypty, oraz oszczędny dobór obcych skryptów.

Dlaczego ciasteczka z SameSite=None niemal zawsze niosą też Secure?

Bo Chrome i pozostałe przeglądarki oparte na Chromium od 2020 roku w ogóle nie przyjmują ciasteczka z SameSite=None bez Secure. Ciasteczko wyraźnie dopuszczone do zapytań z innych witryn musi więc być ograniczone do połączeń szyfrowanych.

Źródła

Lukas Wójcik

Lukas Wójcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Kontakt

Masz pytanie lub pomysł na projekt internetowy? Napisz krótko, o co chodzi. Formularz korzysta z reCAPTCHA do ochrony przed spamem.

Napisanie komentarza

Obserwacje z innych wdrożeń, zastrzeżenia i pytania są tu mile widziane.

Adres e-mail nie jest publikowany. Pola obowiązkowe oznaczono gwiazdką.