Пошук уроків, статей та іншого контенту
Три способи зберегти дані в браузері — і чому вибір неправильного може ненавмисно розлогінити користувача або передати зайві дані на сервер.
Браузер надає щонайменше три різні місця зберегти невеликі дані на стороні клієнта — localStorage, sessionStorage і cookies (курс JavaScript, урок «Форми та збереження даних: localStorage, sessionStorage»). Вони різняться не за API (усі три — по суті пари ключ-значення у вигляді рядків), а за тим, як довго дані живуть і хто їх бачить.
localStorage.setItem("theme", "dark");
const theme = localStorage.getItem("theme");
localStorage.removeItem("theme");Дані зберігаються, доки їх явно не видалять (кодом чи користувачем через налаштування браузера) — переживають закриття вкладки, перезапуск браузера й навіть перезавантаження комп'ютера. Доступні лише JavaScript цього ж origin (протокол + домен + порт) і ніколи не надсилаються на сервер автоматично.
sessionStorage.setItem("draftText", "Незбережений чернетковий текст...");Той самий API, що й localStorage, але дані очищуються, щойно закривається конкретна вкладка/вікно браузера — навіть та сама сторінка, відкрита в іншій вкладці одночасно, має власне, ізольоване sessionStorage. Підходить для тимчасових даних одного сеансу роботи (стан незбереженої форми, крок майстра налаштувань).
document.cookie = "sessionId=abc123; max-age=3600; path=/; secure; samesite=strict";На відміну від двох попередніх, cookies автоматично надсилаються браузером у заголовку кожного HTTP-запиту до відповідного домену — саме тому вони історично використовувались для сесій автентифікації: сервер встановлює cookie один раз, і браузер сам додає її до кожного наступного запиту без жодного додаткового коду на клієнті.
Ця сама «автоматичність» — джерело реального ризику: cookies без прапорця secure передаються навіть по незашифрованому HTTP, а без HttpOnly доступні клієнтському JavaScript — а отже й будь-якому XSS-скрипту, що встиг виконатись на сторінці. Сесійні cookies зазвичай мають бути одночасно HttpOnly, Secure і SameSite.
localStorage — без терміну придатності, лише клієнт, ~5-10МБ на origin, ідеально для налаштувань UI (тема, мова інтерфейсу), яких серверу знати не потрібно.
sessionStorage — живе до закриття вкладки, лише клієнт, той самий обсяг, підходить для тимчасового стану одного сеансу (чернетка форми, стан майстра кроків).
Cookies — термін придатності налаштовується явно, автоматично надсилаються на сервер із кожним запитом, обмежені ~4КБ, історичний і досі поширений вибір для сесій автентифікації саме через автоматичну передачу на сервер.
Зберігати чутливі токени автентифікації в localStorage «бо простіше через JavaScript» — на відміну від HttpOnly cookies, localStorage повністю доступний будь-якому JavaScript-коду на сторінці, включно зі шкідливим кодом при успішній XSS-атаці.
Зберігати великі обсяги даних у cookies — вони надсилаються з абсолютно кожним HTTP-запитом до домену (включно із запитами по зображення, стилі, шрифти), тож зайві кілобайти в cookie сповільнюють кожен запит непомітно, але постійно.
Очікувати, що sessionStorage «синхронізується» між вкладками того самого сайту — кожна вкладка має власне ізольоване sessionStorage; для даних, що мають бути спільними між вкладками, підходить localStorage (разом із подією storage для реакції на зміни з інших вкладок) чи BroadcastChannel API.
localStorage і sessionStorage — клієнтські сховища з однаковим API, що різняться лише терміном життя (без обмеження vs до закриття вкладки) і ніколи автоматично не потрапляють на сервер. Cookies менші за обсягом, але автоматично надсилаються на сервер із кожним запитом — саме тому історично використовуються для сесій автентифікації, і саме тому чутливі значення в cookies мають бути захищені прапорцями HttpOnly, Secure і SameSite.