Strona sklepu pamięta zawartość koszyka, serwis nie wyrzuca użytkownika po każdym kliknięciu, a wybrany motyw ciemny pozostaje aktywny przy następnej wizycie. Te wygodne drobiazgi są możliwe między innymi dzięki plikom cookie. Choć ich nazwa pojawia się dziś głównie w banerach prywatności, pierwotnie rozwiązują one bardzo techniczny problem: protokół HTTP sam z siebie nie pamięta poprzednich żądań.
Cookie nie jest programem uruchamianym na komputerze ani ukrytym plikiem, który samodzielnie przegląda dysk. To niewielka porcja danych powiązana z określoną witryną. Przeglądarka zapisuje ją zgodnie z instrukcją serwera, a później dołącza do pasujących żądań. Dopiero sposób użycia tej informacji decyduje, czy pomaga utrzymać sesję, zapamiętuje ustawienie, mierzy ruch czy służy do śledzenia.
Dlaczego HTTP potrzebował pamięci
Gdy przeglądarka pobiera dokument, obraz albo arkusz stylów, wysyła żądanie HTTP, a serwer odpowiada. Kolejne żądanie jest z punktu widzenia samego protokołu nową sprawą. Bez dodatkowego mechanizmu serwer nie wie, że osoba otwierająca drugą podstronę to ten sam klient, który przed chwilą się zalogował lub dodał produkt do koszyka.
Mechanizm opisany w RFC 6265 wprowadza dwa kluczowe nagłówki. Serwer może umieścić w odpowiedzi nagłówek Set-Cookie, na przykład z losowym identyfikatorem sesji. Przeglądarka zapisuje wartość, jeśli spełnia ona reguły, a przy późniejszym żądaniu do odpowiedniej witryny przesyła ją w nagłówku Cookie. Serwer rozpoznaje identyfikator i odnajduje przypisany do niego stan po swojej stronie.
To ważne rozróżnienie: cookie często nie zawiera historii zakupów, hasła ani całego profilu. Może przechowywać tylko przypadkowo wyglądający ciąg znaków będący kluczem do danych zapisanych na serwerze. Jeżeli sklep kojarzy taki klucz z koszykiem, przeglądarka nie musi za każdym razem wysyłać całej listy produktów.
Sesja, data wygaśnięcia i zakres działania
Cookie sesyjne zazwyczaj istnieje do końca sesji przeglądarki, choć współczesne programy potrafią odtwarzać zamknięte karty i wraz z nimi stan sesji. Cookie trwałe otrzymuje datę wygaśnięcia albo parametr Max-Age. Dzięki temu ustawienie języka lub informacja o zaakceptowaniu komunikatu może przetrwać ponowne uruchomienie urządzenia.
Serwer określa również, gdzie przeglądarka może wysłać daną wartość. Atrybuty Domain i Path ograniczają ją do domeny oraz wybranej części serwisu. Brak swobody jest celowy: cookie ustawione przez jedną witrynę nie powinno automatycznie wędrować do każdej innej. Szczegółowo wyjaśnia to aktualizowany przewodnik MDN dotyczący cookies.
Pierwsza i trzecia strona to nie rodzaj pliku, lecz kontekst
Cookie pierwszej strony pochodzi z witryny, którą użytkownik świadomie otworzył. Może odpowiadać za logowanie, zawartość koszyka albo preferencje interfejsu. Cookie trzeciej strony jest związane z innym podmiotem, którego element załadowano wewnątrz odwiedzanej strony, na przykład z systemem reklamowym lub osadzonym narzędziem analitycznym.
Ta sama domena zewnętrzna może pojawić się na wielu różnych stronach. Jeżeli przeglądarka przesyła jej ten sam identyfikator, usługodawca może łączyć wizyty w szerszy profil. To właśnie ten scenariusz stał się źródłem największych sporów o prywatność. MDN opisuje cookies firm trzecich jako jedną z technik umożliwiających śledzenie aktywności między witrynami, ale przypomina też o legalnych zastosowaniach, takich jak osadzanie usług czy utrzymanie stanu widżetu.
Przeglądarki coraz mocniej ograniczają taki obieg, stosując blokowanie, partycjonowanie lub dodatkowe reguły. Nie oznacza to jednak końca wszystkich cookies. Mechanizm pierwszej strony nadal jest podstawowym narzędziem utrzymywania sesji. Zniknięcie każdego cookie unieruchomiłoby wiele zwyczajnych funkcji WWW.
Trzy atrybuty, które chronią sesję
Secure
Atrybut Secure nakazuje wysyłać cookie tylko przez szyfrowane połączenie HTTPS. Chroni to przed przypadkowym ujawnieniem wartości w zwykłym ruchu HTTP. Nie sprawia jednak, że sama witryna staje się uczciwa ani że identyfikator nie może zostać skradziony inną drogą.
HttpOnly
HttpOnly blokuje odczyt cookie przez typowy kod JavaScript działający w stronie. Jest to szczególnie ważne dla identyfikatorów sesji. Jeżeli w aplikacji pojawi się luka pozwalająca uruchomić obcy skrypt, ograniczenie utrudnia bezpośrednie skopiowanie takiego identyfikatora. Nie usuwa całego ryzyka, bo złośliwy kod może nadal próbować wykonywać działania w imieniu zalogowanej osoby.
SameSite
SameSite określa, w jakich sytuacjach cookie może towarzyszyć żądaniu zainicjowanemu z innej witryny. Warianty Strict, Lax i None dają różny kompromis między ochroną a zgodnością z mechanizmami logowania, płatności czy osadzania treści. Według wytycznych OWASP dotyczących zarządzania sesją bezpieczna konfiguracja powinna łączyć odpowiednio dobrane Secure, HttpOnly i SameSite, a identyfikator musi być losowy i trudny do odgadnięcia.
Dlaczego baner nie pyta po prostu o „cookies”
Technicznie podobne pliki mogą pełnić zupełnie różne role. Jeden utrzymuje zalogowanie, drugi zapamiętuje język, trzeci zlicza wizyty, a czwarty pomaga dopasować reklamę na podstawie aktywności w wielu miejscach. Dlatego rozsądny panel zgód dzieli zastosowania na kategorie i pozwala odrzucić rozwiązania opcjonalne bez wyłączania tych koniecznych do działania zamówionej usługi.
W europejskim podejściu ważne jest nie samo słowo „zgoda”, lecz jej jakość. Wytyczne Europejskiej Rady Ochrony Danych podkreślają, że zgoda powinna być dobrowolna, konkretna, świadoma i jednoznaczna. Zaznaczenie opcji z góry albo utrudnienie odmowy nie daje użytkownikowi równorzędnego wyboru. Jednocześnie nie każdy element pamięci używany wyłącznie do wykonania żądanej funkcji jest traktowany tak samo jak narzędzie marketingowe.
Co dzieje się po usunięciu cookies
Wyczyszczenie cookies zwykle wylogowuje z serwisów, usuwa część preferencji i opróżnia koszyki powiązane tylko z lokalnym identyfikatorem. Nie kasuje jednak automatycznie konta, zamówień ani danych zapisanych przez usługę na jej serwerach. Usunięcie klucza z przeglądarki i skasowanie całej bazy po stronie firmy to dwie różne operacje.
Tryb prywatny także nie czyni użytkownika niewidzialnym. Najczęściej tworzy oddzielny, tymczasowy magazyn danych i usuwa go po zamknięciu wszystkich prywatnych okien. Dostawca internetu, administrator sieci oraz odwiedzane serwisy nadal widzą połączenia w zakresie wynikającym z użytej technologii. Tryb ten jest świetny do rozdzielania sesji i ograniczania śladów na wspólnym urządzeniu, ale nie jest peleryną anonimowości.
Mały mechanizm, duża odpowiedzialność
Cookie jest prostą odpowiedzią na brak pamięci w HTTP. Bez niego współczesna sieć byłaby znacznie mniej wygodna, a wiele funkcji wymagałoby ciągłego ponownego uwierzytelniania. Problem zaczyna się nie w chwili zapisania kilku bajtów, lecz wtedy, gdy identyfikator zostaje źle zabezpieczony, działa zbyt długo, trafia do zbyt wielu miejsc albo służy do celu, którego użytkownik nie rozumie.
Dla odwiedzającego najważniejsze jest rozróżnienie funkcji od śledzenia. Dla twórcy serwisu liczy się minimalny zakres, krótki czas życia, poprawne atrybuty bezpieczeństwa i jasna informacja o celu. Pliki cookie nie są ani cyfrowym złem, ani magiczną pamięcią internetu. Są narzędziem, którego skutki zależą od projektu, konfiguracji i uczciwości usługi.