Bezpieczeństwo — czego nigdy nie przechowywać w magazynie

localStorage i sessionStorage zapisują dane na dysku w profilu użytkownika w postaci niezaszyfrowanej. Każdy proces mający dostęp do systemu plików — w tym złośliwe oprogramowanie, narzędzia do tworzenia kopii zapasowych lub inny zalogowany użytkownik — może odczytać każdą zapisaną wartość bez korzystania z przeglądarki.

Wszystkie skrypty działające w obrębie originu współdzielą ten sam magazyn Storage. Udany atak XSS, przejęty zestaw SDK firmy trzeciej lub złośliwe rozszerzenie przeglądarki może wywołać localStorage.getItem i wyprowadzić każdą przechowywaną wartość. Nie istnieje izolacja na poziomie skryptu.

Nie należy umieszczać tokenów sesji, JWT, tokenów odświeżania ani kluczy API w localStorage. Jeśli napastnik wstrzyknie pojedynczą linię JavaScriptu, token natychmiast wycieknie. Należy używać ciasteczek httpOnly, Secure, SameSite, aby token nigdy nie był dostępny z poziomu JavaScriptu.

Przechowywanie haseł w dowolnej postaci — zwykłego tekstu, skrótu lub postaci zaszyfrowanej — po stronie klienta jest niewłaściwe. Haszowanie po stronie klienta nie pomaga, ponieważ napastnik może odczytać skrót i użyć go ponownie. Obsługa haseł należy w całości do serwera i powinna korzystać z dedykowanego mechanizmu haszowania haseł, takiego jak bcrypt.

PCI-DSS zabrania przechowywania numerów kart, kodów CVV, danych paska magnetycznego oraz dat ważności w pamięci po stronie klienta. Zamiast tego używaj dostawcy płatności z tokenizacją (Stripe, Braintree, Adyen), który zwraca krótkotrwały token powiązany z originem aplikacji.

Dokumenty tożsamości, pełne daty urodzenia, adresy zamieszkania i dane medyczne przyciągają uwagę organów regulacyjnych (GDPR, HIPAA) oraz napastników. Przechowuj tylko to, co jest wymagane w bieżącej sesji, proś o te dane ponownie, gdy są potrzebne, a serwer traktuj jako źródło prawdy.

Podatność XSS ujawniająca document.cookie jest poważnym problemem. Ta sama podatność na stronie przechowującej tokeny w localStorage przekazuje napastnikowi od razu każdą przechowywaną wartość. Traktuj localStorage jako powierzchnię ataku zgodną z zasadą: „jeśli jeden skrypt został przejęty, wszystko zostało przejęte”.

Szyfrowanie wartości za pomocą klucza, który również znajduje się w JavaScript, nie zapewnia rzeczywistej ochrony — napastnik, który może odczytać szyfrogram, może także odczytać klucz. Rzeczywiste sekrety muszą pozostać po stronie serwera i być wydawane ponownie, a nie utrwalane po stronie klienta.

Preferencje interfejsu użytkownika (motyw, zwinięty panel boczny, język), niewrażliwe flagi funkcji, zawartość roboczych formularzy i tymczasowy stan kreatora można bezpiecznie przechowywać. Są one i tak widoczne dla użytkownika, a ich ujawnienie nie umożliwia przejęcia konta.

Przekazuj dane uwierzytelniające za pomocą Set-Cookie: token=...; HttpOnly; Secure; SameSite=Strict. Flaga HttpOnly sprawia, że cookie jest niedostępne dla JavaScript, co neutralizuje większość payloadów XSS wykradających tokeny, nawet gdy na stronie występują inne błędy.

Jeśli musisz buforować dane wyglądające na wrażliwe, ogranicz ich zakres (krótki TTL, usuwanie podczas wylogowania, usuwanie przy zamknięciu karty za pomocą sessionStorage), zastosuj restrykcyjną politykę Content Security Policy blokującą wstrzyknięte skrypty i przeprowadź audyt każdego skryptu zewnętrznego uruchamianego na stronach wymagających uwierzytelnienia.

Dlaczego tokeny uwierzytelniające przechowywane w localStorage uważa się za zagrożenie bezpieczeństwa?

Web Storage przechowuje dane w postaci jawnego tekstu, jest dostępny dla skryptów i współdzielony w ramach originu. Nigdy nie umieszczaj tam tokenów uwierzytelniających, haseł, danych płatniczych ani regulowanych informacji osobowych. Przechowuj sekrety w cookie httpOnly, a localStorage rezerwuj na nieszkodliwy stan interfejsu, który użytkownik i tak mógłby zobaczyć.