Czym są localStorage i sessionStorage?

localStorage i sessionStorage to dwa mechanizmy dostarczane przez Web Storage API, standard wbudowany w każdą nowoczesną przeglądarkę. Pozwalają one witrynom internetowym przechowywać pary klucz-wartość bezpośrednio w przeglądarce odwiedzającego, bez angażowania serwera przy każdym ładowaniu strony. Jeśli kiedykolwiek włączyłeś tryb ciemny na witrynie i zauważyłeś następnego dnia, że Twoja preferencja nadal tam była, witryna prawdopodobnie zapisała ten wybór w localStorage.

Jak działa Web Storage API

Web Storage API jest celowo proste. Wywołujesz localStorage.setItem('klucz', 'wartosc'), aby zapisać dane, localStorage.getItem('klucz'), aby odczytać, i localStorage.removeItem('klucz'), aby usunąć. sessionStorage używa dokładnie tych samych metod. Oba systemy storage akceptują tylko stringi, więc obiekty są zwykle serializowane za pomocą JSON.stringify() przed zapisaniem. Nie ma języka zapytań, nie ma indeksowania ani struktury relacyjnej. To płaska pamięć klucz-wartość zaprojektowana do szybkich, lekkich operacji odczytu i zapisu.

localStorage vs. sessionStorage: kluczowe różnice

• Persystencja: dane localStorage pozostają w przeglądarce, dopóki użytkownik lub witryna ich jawnie nie usunie. Nie ma daty wygaśnięcia. Dane sessionStorage są natomiast czyszczone w momencie zamknięcia karty przeglądarki.
• Zakres między kartami: localStorage jest współdzielony między wszystkimi kartami i oknami należącymi do tej samej origin (protokół + domena + port). sessionStorage jest izolowany na kartę. Jeśli otworzysz tę samą stronę w dwóch kartach, każda karta ma własny sessionStorage.
• Limity storage: oba zazwyczaj oferują od 5 do 10 MB na origin, w zależności od przeglądarki. Chrome i Firefox mają domyślnie około 5 MB na origin na storage. Safari może być bardziej restrykcyjny, zwłaszcza w trybie prywatnym, gdzie czasami ogranicza storage do zaledwie kilkuset kilobajtów.
• Zachowanie sieciowe: ani localStorage, ani sessionStorage nie są wysyłane z żądaniami HTTP do serwera. To fundamentalna różnica w stosunku do cookies, które są automatycznie dołączane do każdego nagłówka żądania.

Co zazwyczaj przechowują witryny WordPress

Wtyczki i motywy WordPress używają storage przeglądarki do szerokiego zakresu celów. Oto najczęstsze:

• Preferencje motywu: przełączniki trybu ciemnego, stan zwinięcia/rozwinięcia paska bocznego, wybory rozmiaru czcionki. Te są prawie zawsze zapisywane w localStorage, ponieważ muszą przetrwać zamknięcie karty.
• Dane koszyka: WooCommerce i podobne wtyczki czasami cache'ują fragmenty koszyka w localStorage, aby uniknąć dodatkowych podróży do serwera przy wyświetlaniu mini-koszyka w nagłówku.
• Wersje robocze formularzy: wtyczki formularzy kontaktowych mogą automatycznie zapisywać wejście użytkownika w sessionStorage, aby częściowo wypełniony formularz nie zaginął, jeśli użytkownik przypadkowo odejdzie i wróci przyciskiem wstecz.
• Wybory zgody na cookies: niektóre wtyczki banerów zgody (takie jak Complianz lub CookieYes) zapisują status zgody odwiedzającego w localStorage zamiast w cookie, choć użycie cookie jest częstsze.
• Stan UI administratora: sam panel administracyjny WordPress używa obu mechanizmów storage. Na przykład pamięta, które metaboksy są zwinięte, które kolumny są widoczne w liście wpisów i czy menu administratora jest zwinięte.
• Bufory analityki i śledzenia: niektóre skrypty analityczne batchują zdarzenia w localStorage i wysyłają je w grupach na serwer, aby zmniejszyć żądania sieciowe.

Rozważania bezpieczeństwa

Web Storage jest wygodne, ale niesie ze sobą rzeczywiste kompromisy bezpieczeństwa, które deweloperzy powinni zrozumieć.

• Narażenie na XSS: każdy JavaScript działający na stronie może odczytywać localStorage i sessionStorage. Jeśli atakujący zdoła wstrzyknąć skrypt przez lukę cross-site scripting (XSS), może wyciągnąć dowolną zapisaną wartość. Cookies mogą być chronione flagą HttpOnly, która całkowicie blokuje dostęp JavaScript. Nie ma równoważnej ochrony dla Web Storage.
• Polityka same-origin: storage jest ograniczony do origin, co oznacza, że https://example.com nie może odczytywać storage z https://other.com. Jednak każdy skrypt na tym samym origin, w tym skrypty zewnętrzne, które ładujesz (analityka, sieci reklamowe, widgety czatu), ma pełny dostęp do tego samego storage.
• Brak szyfrowania: dane są przechowywane jako zwykły tekst na dysku. Każdy z fizycznym dostępem do urządzenia lub malware działający na urządzeniu może je odczytać. Nigdy nie przechowuj haseł, tokenów ani innych wrażliwych danych uwierzytelniających w Web Storage.
• Brak walidacji po stronie serwera: ponieważ dane żyją tylko w przeglądarce, użytkownik lub skrypt może je swobodnie modyfikować. Nigdy nie polegaj na wartościach Web Storage dla autoryzacji lub decyzji bezpieczeństwa na serwerze.

GDPR i implikacje prywatności

W ramach GDPR i dyrektywy ePrivacy localStorage i sessionStorage są traktowane tak samo jak cookies pod względem wymagań dotyczących zgody. Zasada prawna jest neutralna technologicznie: jeśli przechowujesz lub odczytujesz informacje na urządzeniu użytkownika w celu, który nie jest ściśle konieczny dla usługi, o którą użytkownik prosił, potrzebujesz zgody. Oznacza to, że koszyk WooCommerce zapisany w localStorage jest prawdopodobnie "ściśle konieczny" i nie wymaga zgody. Ale identyfikator analityki zapisany w localStorage do śledzenia powracających odwiedzających zdecydowanie wymaga zgody. Wielu właścicieli witryn przegapia to, ponieważ narzędzia zgody na cookies tradycyjnie skupiają się na cookies, ale organy regulacyjne jasno dały do zrozumienia, że zasady stosują się do wszystkich technologii storage po stronie klienta.

Web Storage vs. cookies: kiedy którego używać

• Użyj cookies: gdy serwer musi odczytać wartość przy każdym żądaniu (identyfikatory sesji, tokeny uwierzytelniania), gdy potrzebujesz ochrony HttpOnly przed XSS lub gdy potrzebujesz precyzyjnej kontroli wygaśnięcia.
• Użyj localStorage: gdy musisz zachować preferencje po stronie klienta lub cache'ować dane między sesjami, dane nie muszą podróżować do serwera, a dane nie są wrażliwe.
• Użyj sessionStorage: gdy dane muszą żyć tylko przez czas trwania pojedynczej sesji karty, takie jak postęp kreatora formularza, tymczasowy stan UI lub tokeny przekierowania jednorazowego użytku.

Porównanie wydajności

Czytanie i pisanie do Web Storage jest synchroniczne i dzieje się na głównym wątku. Dla małych ilości danych jest to szybkie, zwykle poniżej milisekundy. Ale jeśli strona zapisuje lub odczytuje duże ilości danych przy każdej interakcji, może to powodować jank. Cookies natomiast dodają narzut w inny sposób: zwiększają rozmiar każdego nagłówka żądania HTTP, co spowalnia każde wywołanie sieciowe. Do przechowywania kilku małych wartości oba podejścia działają dobrze. Dla większych zestawów danych (dziesiątki KB lub więcej) rozważ IndexedDB, które jest asynchroniczne i nie blokuje głównego wątku.

Jak inspekcjonować storage w DevTools

Każda duża przeglądarka pozwala inspekcjonować Web Storage. W Chrome DevTools (F12) przejdź do zakładki Application i znajdź "Local Storage" i "Session Storage" w lewym pasku bocznym. Możesz zobaczyć każdą parę klucz-wartość, ręcznie edytować wartości i usuwać elementy. Firefox ma podobny panel pod zakładką Storage. Jest to najprostszy sposób, aby zobaczyć dokładnie, co witryna WordPress przechowuje w Twojej przeglądarce, i rozwiązać nieoczekiwane zachowanie.

Co sprawdza InspectWP

InspectWP wymienia wszystkie wpisy localStorage i sessionStorage ustawione przez Twoją witrynę WordPress podczas skanowania. Daje Ci to jasny obraz tego, co Twoja witryna przechowuje po stronie klienta, które wtyczki są odpowiedzialne i czy niektóre wpisy mogą budzić obawy o prywatność w ramach zasad GDPR lub ePrivacy.