Cookie, localStorage czy sesja — gdzie trzymać dane

Aplikacja webowa musi coś o użytkowniku pamiętać: że jest zalogowany, co ma w koszyku, jaki wybrał motyw. Miejsc do wyboru jest kilka i różnią się bardziej, niż mogłoby się wydawać.

Cookie

Mały kawałek tekstu zapisany w przeglądarce, który dołącza się automatycznie do każdego żądania do serwera. To jedyny z tych mechanizmów, o którym serwer wie bez dodatkowej pracy — i dlatego trzymamy w nim identyfikator sesji.

Ma limit około 4 kilobajtów i termin ważności. Przy ciasteczkach logowania zawsze ustawiaj trzy flagi:

• HttpOnly — JavaScript nie ma do niego dostępu, więc nie ukradnie go wstrzyknięty skrypt,
• Secure — wysyłane wyłącznie po HTTPS,
• SameSite — nie doklei się do żądania z obcej strony, co blokuje część ataków.

localStorage

Około 5 megabajtów miejsca w przeglądarce, dane zostają po zamknięciu karty i nigdy same nie lecą na serwer. Idealne na drobne wygody: wybrana zakładka, zwinięty panel, tryb ciemny, niewysłany szkic formularza.

Nigdy nie trzymaj tu tokenów logowania ani danych osobowych. Każdy skrypt na stronie — także ten doklejony przez wtyczkę lub reklamę — czyta localStorage bez przeszkód.

sessionStorage

To samo co localStorage, tylko znika po zamknięciu karty i nie jest współdzielone między kartami. Pasuje do stanu jednego procesu: krok formularza wieloetapowego, filtry na liście produktów.

Sesja serwerowa

Dane leżą na serwerze, a przeglądarka trzyma jedynie identyfikator w ciasteczku. To najbezpieczniejsze miejsce na wszystko, co wrażliwe: kto jest zalogowany, jakie ma uprawnienia, co jest w koszyku przed złożeniem zamówienia.

Użytkownik nie może tych danych podejrzeć ani podmienić — widzi tylko losowy ciąg znaków.

Ściągawka

Prosta zasada na koniec: jeśli podmiana wartości przez użytkownika mogłaby mu coś dać, dane muszą siedzieć na serwerze. Cena produktu w localStorage to zaproszenie do zakupów za złotówkę.