В чем разница между LocalStorage, SessionStorage и Cookies?

Ответ

Это три основных механизма хранения данных на стороне клиента, и понимание их различий критично для тестирования веб-приложений (функциональность, безопасность, кросс-табличные сценарии).

Критерий Cookies LocalStorage SessionStorage
Объем ~4 КБ на домен ~5-10 МБ на домен ~5-10 МБ на домен
Время жизни Задается параметрами Expires или Max-Age. Могут быть сессионными (до закрытия браузера). Сохраняются до явного удаления (JS или очистка браузера). Удаляются при закрытии вкладки браузера.
Доступность Доступны как на клиенте (document.cookie), так и на сервере (передаются в заголовках Cookie каждого HTTP-запроса). Доступны только в контексте клиентского JavaScript (window.localStorage). Доступны только в контексте клиентского JavaScript (window.sessionStorage) и только в рамках одной вкладки.
Использование в тестировании Аутентификация (токены), отслеживание сессии, персонализация. Сохранение больших непередаваемых на сервер данных (настройки UI, кэш данных). Временное хранение данных в рамках одной сессии/вкладки (например, данные формы при переходе между шагами).

Практические сценарии для QA:

  1. Тестирование Cookies (безопасность): Проверка флагов HttpOnly (защита от XSS), Secure (только по HTTPS), SameSite (защита от CSRF).
  2. Тестирование LocalStorage:
    // Проверка сохранения/загрузки данных
    localStorage.setItem('theme', 'dark');
    console.assert(localStorage.getItem('theme') === 'dark');
    // Проверка очистки при логауте
    logoutFunction(); // Должна вызывать localStorage.clear() или removeItem
    console.assert(localStorage.getItem('theme') === null);
  3. Тестирование SessionStorage (изоляция вкладок):
    • Открыть приложение в двух вкладках.
    • В первой вкладке сохранить данные: sessionStorage.setItem('wizardStep', '2').
    • Убедиться, что во второй вкладке sessionStorage.getItem('wizardStep') вернет null.
    • Закрыть и заново открыть вкладку — данные должны быть утеряны.
  4. Очистка данных: Важно проверять, как приложение ведет себя после ручной очистки хранилища в настройках браузера — не должно приводить к критичным ошибкам.

Ответ 18+ 🔞

А, ну это ж классика, про которую каждый тестировщик должен знать, как свои пять пальцев. Смотри, тут три главных хранилища в браузере, и если их не различать — можно такого натестировать, что потом разработчики тебя самого в localStorage запрячут, чтоб не доставал.

Вот смотри, таблица, чтобы всё в голове разложилось, а не как попало.

Критерий Cookies LocalStorage SessionStorage
Объем ~4 КБ на домен ~5-10 МБ на домен ~5-10 МБ на домен
Время жизни Задается параметрами Expires или Max-Age. Могут быть сессионными (до закрытия браузера). Сохраняются до явного удаления (JS или очистка браузера). Удаляются при закрытии вкладки браузера.
Доступность Доступны как на клиенте (document.cookie), так и на сервере (передаются в заголовках Cookie каждого HTTP-запроса). Доступны только в контексте клиентского JavaScript (window.localStorage). Доступны только в контексте клиентского JavaScript (window.sessionStorage) и только в рамках одной вкладки.
Использование в тестировании Аутентификация (токены), отслеживание сессии, персонализация. Сохранение больших непередаваемых на сервер данных (настройки UI, кэш данных). Временное хранение данных в рамках одной сессии/вкладки (например, данные формы при переходе между шагами).

А теперь, блядь, на пальцах, что с этим делать на практике:

  1. Cookies — это святое, их трогать нужно в белых перчатках. Тут главное — безопасность, ёпта. Ты должен проверять, как будто ты хакер-неудачник. Есть ли у куки флаг HttpOnly? Если нет — это прямая дорога для XSS, чтобы тебе скрипт твой же токен украл. Флаг Secure стоит? Или он по HTTP летает, как голый по проспекту? А SameSite? Без него любая сторонняя сайта может сделать запрос с твоими куками — вот тебе и CSRF, привет. В общем, доверия ебать ноль, проверяй всё.

  2. LocalStorage — это твой чердак, где можно хранить овердохуища хлама. Но следи, чтобы приложение не превратилось в свинарник. Вот смотри, как проверять:

    // Проверка сохранения/загрузки данных
    localStorage.setItem('theme', 'dark');
    console.assert(localStorage.getItem('theme') === 'dark');
    // Проверка очистки при логауте
    logoutFunction(); // Должна вызывать localStorage.clear() или removeItem
    console.assert(localStorage.getItem('theme') === null);

    Главный сценарий: залогинился, накричал настроек, разлогинился. После этого зайди в DevTools, в Application, и посмотри — не осталось ли там чего? Если осталось — это пиздец, утечка данных. А ещё представь, что юзер — тот ещё распиздяй, и просто взял и очистил всё хранилище в настройках браузера. Приложение не должно накрыться медным тазом с ошибкой, а просто взять и перейти в дефолтное состояние.

  3. SessionStorage — это как память золотой рыбки, только на одну вкладку. Тут хитрая жопа с изоляцией.

    • Открой приложение в двух вкладках. В одной сохрани что-то: sessionStorage.setItem('wizardStep', '2').
    • Перейди на другую вкладку и попробуй это прочитать. Должно быть null, ни хуя себе, да? Потому что это другая сессия.
    • Закрой вкладку и открой заново — всё, данные испарились, как твоя зарплата в конце месяца. Если не испарились — вот тебе и баг.

Короче, суть в чём: нужно понимать, где что лежит, кто к этому имеет доступ и когда это всё сдохнет. И тогда ты не будешь, как тот чувак, искать в localStorage сессионный токен, который на сервере сидит в куках. Э, сабака сука, думай головой!