Краткий ответ: SessionStorage и localStorage — это оба браузерные веб-API хранения, которые позволяют веб-сайтам сохранять данные на устройстве пользователя, но они критически различаются по постоянству и области применения. localStorage сохраняет данные на неопределенный срок между сессиями и вкладками, в то время как sessionStorage стирает данные при закрытии вкладки браузера. С точки зрения конфиденциальности localStorage несет значительно более высокий риск, поскольку данные остаются без истечения срока действия, что делает его более привлекательной целью для отслеживания, отпечатков пальцев и регуляторного контроля в рамках таких систем, как GDPR.
Основные выводы
- localStorage сохраняется на неопределенный срок, пока не будет явно очищен; sessionStorage удаляется при закрытии вкладки или окна.
- Оба типа хранения уязвимы к атакам межсайтового скриптинга (XSS) и не предлагают встроенного шифрования.
- Данные ни localStorage, ни sessionStorage не передаются на сервер автоматически, в отличие от файлов cookie, но оба полностью читаемы любым JavaScript, работающим в том же источнике.
- Скрипты третьих сторон, загруженные на странице, могут получить доступ к данным localStorage, если они выполняются в контексте того же источника.
- В соответствии с GDPR хранение несущественных данных в localStorage без согласия пользователя является нарушением соблюдения, так же как и установка отслеживающих файлов cookie.
- Чувствительные данные, такие как токены аутентификации, пароли и личная информация (PII), никогда не должны храниться в любом из механизмов без дополнительных уровней безопасности.
- Приватный/инкогнито просмотр ограничивает сохранение localStorage, но не устраняет риски sessionStorage в рамках одной сессии.
- Разработчики должны предпочитать sessionStorage для временного состояния, серверные сессии или HttpOnly файлы cookie для аутентификации и платформу управления согласиями, такую как Biscotti CMP, для управления согласиями на хранение.
В чем разница между SessionStorage и LocalStorage?
SessionStorage и localStorage являются частью HTML5 Web Storage API, но они служат различным целям, определяемым их постоянством и поведением в рамках вкладки.
localStorage хранит пары ключ-значение без срока действия. Данные выживают после перезапусков браузера, перезагрузок системы и неопределенных периодов бездействия, пока пользователь или приложение явно не удалят их. Он общий для всех вкладок и окон, работающих под одним и тем же источником (протокол + домен + порт). [1][5]
sessionStorage хранит данные только на время сессии страницы. Когда пользователь закрывает вкладку или окно, данные исчезают. Критически важно, что каждая вкладка поддерживает свою собственную изолированную sessionStorage, открытие того же URL во второй вкладке не делит данные sessionStorage первой вкладки. [1]
| Особенность | localStorage | sessionStorage |
|---|---|---|
| Постоянство | Неопределенное | Только время жизни вкладки/окна |
| Общий для вкладок | Да (один и тот же источник) | Нет (изоляция по вкладкам) |
| Выживает при перезагрузке страницы | Да | Да |
| Выживает при закрытии вкладки | Да | Нет |
| Вместимость | ~5-10 МБ на источник | ~5-10 МБ на источник |
| Передача на сервер | Нет | Нет |
| Защита HttpOnly | Не доступна | Не доступна |
Оба API подчиняются политике одного источника, поэтому страница на https://example.com не может читать хранилище, установленное https://otherdomain.com. [4]
Есть ли у localStorage риски конфиденциальности по сравнению с sessionStorage?
Да, localStorage несет значительно более высокие риски конфиденциальности, чем sessionStorage, в первую очередь из-за его неопределенного постоянства и доступности между вкладками.
Данные, записанные в localStorage, могут накапливаться в течение месяцев или лет без ведома пользователя. Рекламодатели и аналитические компании исторически использовали localStorage как "супер-файл cookie", идентификатор отслеживания, который выживает после удаления файлов cookie, потому что большинство пользователей не думают о том, чтобы вручную очищать хранилище браузера. sessionStorage, напротив, самоуничтожается при закрытии вкладки, что делает его гораздо менее полезным вектором отслеживания.
Ключевые факторы риска конфиденциальности, уникальные для localStorage:
- Постоянные идентификаторы отслеживания: Уникальный идентификатор, хранящийся в localStorage, может отслеживать пользователя на протяжении нескольких посещений без каких-либо серверных файлов cookie.
- Утечка данных между вкладками: Любой скрипт, работающий в любой вкладке одного и того же источника, может читать все данные localStorage.
- Вещание событий хранения: Изменения в localStorage вызывают событие
storageв других открытых вкладках того же источника, позволяя синхронизацию данных между вкладками, которую пользователи не могут наблюдать. [5] - Нет автоматического истечения срока действия: В отличие от файлов cookie, которые поддерживают атрибуты
Max-AgeиExpires, localStorage не имеет механизма TTL.
Могут ли веб-сайты отслеживать пользователей с помощью localStorage и sessionStorage?
Веб-сайты могут и используют localStorage для постоянного отслеживания. sessionStorage менее полезен для отслеживания, но все же представляет риски наблюдения в рамках одной сессии.
Одна строка JavaScript, localStorage.setItem('uid', 'abc123'), создает постоянный идентификатор, который выживает после очистки файлов cookie. Эта техника, иногда называемая "evercookie" или восстановлением на основе хранилища, была задокументирована в исследованиях конфиденциальности и является причиной, по которой регуляторы все чаще рассматривают localStorage в рамках тех же правил согласия, что и файлы cookie.
sessionStorage может отслеживать поведение в рамках одной сессии (поток страниц, ввод форм, навигационные шаблоны), но эти данные исчезают при закрытии вкладки, ограничивая его полезность для долгосрочного профилирования.
Как долго данные остаются в SessionStorage по сравнению с LocalStorage?
Данные localStorage остаются до тех пор, пока они не будут явно удалены, либо пользователем, очищающим хранилище браузера, либо веб-сайтом, вызывающим localStorage.removeItem() или localStorage.clear(), либо браузером, применяющим квоты хранения. [2]
Данные sessionStorage автоматически удаляются, когда вкладка или окно, создавшее их, закрывается. Они выживают при перезагрузке страницы в той же вкладке, но не передаются в новые вкладки, даже если пользователь дублирует вкладку в некоторых браузерах. [1]
Практическое значение: Если разработчик хранит токен сессии в localStorage вместо sessionStorage, этот токен останется на устройстве после выхода пользователя, если приложение явно не удалит его. Это распространенная и значительная ошибка.
Является ли SessionStorage более конфиденциальным, чем localStorage?
Для большинства случаев использования конфиденциальности да, sessionStorage является более уважительным к конфиденциальности выбором. Его автоматическое удаление при закрытии вкладки означает, что данные не задерживаются, что снижает риск от совместного использования устройства, кражи устройств или судебного анализа.
Тем не менее, sessionStorage не является по своей сути "конфиденциальным". В рамках активной сессии он так же уязвим к атакам XSS, как и localStorage. Любой внедренный скрипт может вызвать sessionStorage.getItem() и эксфильтровать данные в реальном времени. [3]
Выберите sessionStorage, если: данные нужны только для текущего взаимодействия пользователя (например, состояние многошаговой формы, одноразовые токены навигации).
Выберите localStorage, если: данные действительно должны сохраняться между сессиями (например, предпочтения пользовательского интерфейса, не чувствительные настройки), и убедитесь, что они не содержат ничего, что можно было бы идентифицировать.
Какие личные данные никогда не должны храниться в localStorage?
Следующие категории данных никогда не должны храниться в localStorage (и должны обрабатываться с крайней осторожностью даже в sessionStorage): [3]
- Токены аутентификации (JWT, OAuth токены, идентификаторы сессий)
- Пароли или хеши паролей
- Информация о кредитных картах или платежах
- Номера удостоверений, выданные государством, или номера социального страхования
- Полные имена в сочетании с адресами электронной почты или номерами телефонов
- Медицинские или медицинские записи
- Любые данные, классифицированные как "особая категория" в соответствии с GDPR (биометрические данные, данные о здоровье, политические мнения)
Данные, хранящиеся как в localStorage, так и в sessionStorage, по умолчанию не зашифрованы. Любой, имеющий физический доступ к устройству или любой скрипт, способный выполняться на странице, может прочитать их в открытом виде. [3]
Могут ли скрипты третьих сторон получить доступ к данным localStorage?
Скрипты третьих сторон могут получить доступ к данным localStorage, если они загружены и выполняются в том же источнике, что и хост-страница. Это критический и часто недооцененный риск.
Когда веб-сайт встраивает скрипт третьей стороны для аналитики или рекламы через тег <script>, этот скрипт выполняется в контексте источника хост-страницы. Он может свободно читать и записывать в localStorage сайта. Политика одного источника не защищает от скриптов, которые намеренно или случайно включены на странице. [4]
Что это означает на практике: Если сайт хранит идентификатор пользователя в localStorage и также загружает скрипт рекламы третьей стороны, этот рекламный скрипт может прочитать идентификатор и связать его с данными о поведении между сайтами, без ведома или согласия пользователя.
Это одна из причин, почему платформы управления согласиями важны. Biscotti CMP позволяет веб-сайтам управлять и документировать согласие пользователей на операции хранения, включая отслеживание на основе localStorage, помогая сайтам выполнять свои обязательства в соответствии с GDPR и аналогичными системами.
Каковы последствия использования localStorage в соответствии с GDPR?
В соответствии с GDPR любое хранение личных данных или идентификаторов отслеживания, независимо от технического механизма, требует законного основания. Для несущественного отслеживания через localStorage это основание почти всегда является явным согласием пользователя. [2]
Европейский комитет по защите данных подтвердил, что использование localStorage для аналитики, рекламы или профилирования пользователей подпадает под те же требования согласия, что и файлы cookie. Веб-сайты, которые помещают идентификаторы отслеживания в localStorage без предварительного согласия, сталкиваются с теми же рисками соблюдения, что и те, кто использует несогласованные файлы cookie.
Контрольный список соблюдения для localStorage в соответствии с GDPR:
- Проведите аудит всех ключей localStorage, записанных скриптами первой и третьей сторон.
- Классифицируйте каждый ключ: является ли он строго необходимым для услуги или используется для аналитики/рекламы?
- Для несущественного хранения ограничьте операцию записи документированным согласием пользователя.
- Обеспечьте пользователям четкий механизм для отзыва согласия и инициирования удаления хранения.
- Документируйте законный интерес контролера данных или запись согласия.
Правильно настроенная платформа управления согласиями, такая как Biscotti CMP, может автоматизировать большую часть этого жизненного цикла согласия.
Можно ли получить доступ к localStorage с разных веб-сайтов?
Нет. localStorage строго ограничен источником (сочетание протокола + домена + порта), который его создал. Скрипт на https://siteA.com не может читать данные localStorage, установленные https://siteB.com. [4]
Тем не менее, эта защита имеет свои пределы. Если один и тот же поставщик рекламы или аналитики загружает свои скрипты как на siteA.com, так и на siteB.com, каждый экземпляр записывает в соответствующее хранилище localStorage независимо. Затем поставщик сопоставляет данные на стороне сервера, эффективно достигая отслеживания между сайтами, не нарушая политику одного источника.
Как режим инкогнито и приватный просмотр влияют на localStorage?
Приватный/инкогнито просмотр создает временный раздел хранения, который удаляется при закрытии приватного окна. Данные localStorage, записанные во время сессии инкогнито, не сохраняются в основном профиле браузера и недоступны для обычных окон просмотра.
sessionStorage ведет себя так же в инкогнито, как и в обычном просмотре: он удаляется при закрытии вкладки.
Важные оговорки:
- В рамках активной сессии инкогнито localStorage все еще читаем всеми скриптами, работающими в контексте того же источника.
- Режим инкогнито не предотвращает эксфильтрацию данных на основе XSS в реальном времени.
- Некоторые браузеры синхронизируют localStorage между устройствами, если пользователь вошел в систему синхронизации браузера, что может переместить "локальные" данные в облачную инфраструктуру.
Как очистить SessionStorage и localStorage для обеспечения конфиденциальности?
Очистка хранилища браузера проста, но требует целенаправленных действий, поскольку браузеры не делают это автоматически для localStorage.
Очистка на уровне браузера:
- Chrome: Настройки > Конфиденциальность и безопасность > Очистить данные о просмотре > Кэшированные изображения и файлы + Данные сайта
- Firefox: Настройки > Конфиденциальность и безопасность > Файлы cookie и данные сайта > Очистить данные
- Safari: Настройки > Конфиденциальность > Управление данными веб-сайтов
Программная очистка (для разработчиков):
localStorage.clear()удаляет все ключи для источника.sessionStorage.clear()удаляет все ключи для текущей сессии вкладки.localStorage.removeItem('keyName')удаляет конкретный ключ.
Для конечных пользователей, обеспокоенных отслеживанием: очистка "данных сайта" или "файлов cookie и хранилища" в настройках браузера удаляет как содержимое localStorage, так и sessionStorage для всех сайтов. Расширения браузера, разработанные для обеспечения конфиденциальности, могут автоматизировать это на основе сайта или сессии.
Какие распространенные ошибки конфиденциальности совершают разработчики с веб-хранилищем?
Наиболее значительные ошибки имеют общую причину: обращение с клиентским хранилищем так, как будто это безопасная серверная база данных.
- Хранение JWT в localStorage: Токены аутентификации, хранящиеся в localStorage, доступны любому скрипту на странице. Одна уязвимость XSS открывает токен каждого пользователя. Вместо этого используйте HttpOnly файлы cookie для токенов аутентификации.
- Отсутствие логики истечения срока действия: localStorage не имеет TTL. Разработчики, которые хранят данные, не создавая логику истечения срока действия, оставляют устаревшие, чувствительные данные на устройствах на неопределенный срок.
- Предположение, что один источник означает безопасность: Политика одного источника блокирует внешние сайты, но не злонамеренные скрипты, загруженные с того же сайта (XSS, скомпрометированные сторонние библиотеки).
- Игнорирование доступа скриптов третьих сторон: Встраивание аналитических или рекламных скриптов без аудита того, что они читают из localStorage.
- Отсутствие согласия на отслеживание хранения: Запись идентификаторов аналитики в localStorage до получения согласия пользователя, что является прямым нарушением GDPR. [2]
- Хранение избыточной PII: Кэширование ответов API, которые включают полные профили пользователей в localStorage "для производительности", не учитывая поверхность воздействия.
Является ли IndexedDB более конфиденциальным, чем localStorage?
IndexedDB не является по своей сути более конфиденциальным, чем localStorage. Оба подчиняются политике одного источника, оба доступны для JavaScript, работающего на странице, и оба уязвимы к атакам XSS.
IndexedDB предлагает большую вместимость и поддерживает структурированные данные и двоичные блобы, что делает его подходящим для сложных офлайн-приложений. Но с точки зрения конфиденциальности и безопасности риски сопоставимы. Данные, хранящиеся в IndexedDB, также по умолчанию не зашифрованы и сохраняются на неопределенный срок, если не будут явно удалены.
Выбор между IndexedDB и localStorage должен определяться сложностью данных и требованиями к объему, а не предположениями о конфиденциальности. Ни один из них не подходит для чувствительных личных данных без шифрования на уровне приложения и строгих контролей доступа.
Заключение
Дебаты о SessionStorage против LocalStorage: Влияние на конфиденциальность веб-API хранения — это не просто техническая сноска, это имеет прямые последствия для конфиденциальности пользователей, соблюдения нормативных требований и безопасности приложений. Неопределенное постоянство localStorage и доступность между вкладками делают его высокорисковым механизмом хранения при неправильном использовании, в то время как автоматическое удаление sessionStorage при закрытии вкладки делает его более защищенным выбором для временного состояния.
Практические следующие шаги для разработчиков и владельцев веб-сайтов в 2026 году:
- Проведите аудит всего использования localStorage и sessionStorage в скриптах первой и третьей сторон с использованием инструментов разработчика браузера (вкладка Приложение).
- Немедленно удалите любые токены аутентификации, PII или чувствительные идентификаторы из клиентского хранилища.
- Замените хранение токенов аутентификации на основе localStorage на HttpOnly, Secure файлы cookie, управляемые на стороне сервера.
- Реализуйте рабочий процесс управления согласиями, используя платформу, такую как Biscotti CMP, чтобы ограничить несущественные записи в localStorage документированным согласием пользователя.
- Постройте логику истечения срока действия для любых данных localStorage, которые должны сохраняться, и обеспечьте очистку при выходе.
- Проведите аудит скриптов третьих сторон, чтобы понять, какой внешний код может читать из хранилища вашего источника.
- Обучите команды разработки предотвращению XSS как основному вектору атаки против обоих типов хранения.
API веб-хранения — это мощные инструменты. Используемые без соблюдения конфиденциальности, они становятся векторами ответственности. Используемые с целенаправленным ограничением, управлением согласиями и соблюдением безопасности, они служат своей цели, не компрометируя пользователей, которые доверяют вашему приложению.
ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
В: В чем основная разница между sessionStorage и localStorage? localStorage сохраняет данные на неопределенный срок между сессиями и общий для всех вкладок одного и того же источника. sessionStorage хранит данные только на время жизни текущей вкладки и автоматически удаляется при закрытии вкладки.
В: Можно ли использовать localStorage для отслеживания пользователей без файлов cookie? Да. Уникальный идентификатор, хранящийся в localStorage, выживает после удаления файлов cookie и может использоваться для отслеживания пользователей на протяжении нескольких посещений одного и того же сайта, функционируя как постоянный механизм отслеживания.
В: Является ли sessionStorage безопасным для хранения паролей? Нет. sessionStorage не зашифрован и доступен любому JavaScript, работающему на странице, включая внедренные злонамеренные скрипты. Пароли никогда не должны храниться в любом механизме клиентского хранения.
В: Применяется ли GDPR к localStorage? Да. В соответствии с GDPR хранение идентификаторов отслеживания или личных данных в localStorage без законного основания, обычно явного согласия пользователя для несущественных целей, является нарушением соблюдения, эквивалентным использованию несогласованных файлов cookie.
В: Могут ли скрипты третьих сторон читать мои данные localStorage?
Да, если эти скрипты загружены и выполняются в том же источнике. Скрипты аналитики или рекламы третьих сторон, встроенные через теги <script>, выполняются в контексте источника хост-страницы и могут читать все данные localStorage для этого источника.
В: Очищение файлов cookie также очищает localStorage? Не всегда. В большинстве браузеров очистка "файлов cookie" сама по себе не очищает localStorage. Пользователи должны специально очистить "данные сайта" или "файлы cookie и другие данные сайта", чтобы удалить содержимое localStorage.
В: Является ли режим инкогнито безопасным от отслеживания localStorage? Режим инкогнито предотвращает сохранение данных localStorage после закрытия приватного окна, но в рамках активной сессии инкогнито localStorage все еще читаем всеми скриптами на странице.
В: Что мне использовать вместо localStorage для токенов аутентификации? Используйте HttpOnly, Secure, SameSite файлы cookie, управляемые на стороне сервера. Эти файлы cookie недоступны для JavaScript, что устраняет риск кражи токенов на основе XSS, который несет localStorage.
В: Является ли IndexedDB более безопасным, чем localStorage? Нет. IndexedDB подвержен тем же уязвимостям XSS и политике одного источника, что и localStorage. Он предлагает большую вместимость и поддержку структуры данных, но не предоставляет дополнительных гарантий конфиденциальности или безопасности.
В: Сколько данных может хранить localStorage и sessionStorage? Большинство современных браузеров выделяют примерно 5-10 МБ хранилища на источник для каждого типа хранилища, что значительно больше, чем предел в 4 КБ, характерный для файлов cookie. [2]
Ссылки
[1] Sessionstorage - https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage?utm_source=openai
[2] What Is Localstorage Sessionstorage - https://inspectwp.com/en/knowledge-base/what-is-localstorage-sessionstorage?utm_source=openai
[3] Html5 Web Storage Security Risks Safeguarding Localstorage And Sessionstorage - https://www.dopethemes.com/html5-web-storage-security-risks-safeguarding-localstorage-and-sessionstorage/?utm_source=openai
[4] Localstorage - https://javascript.info/localstorage?utm_source=openai
[5] Localstorage Sessionstorage - https://www.w3docs.com/learn-javascript/localstorage-sessionstorage?utm_source=openai
[6] Cookies Vs Localstorage Vs Sessionstorage What Each One Exactly Means - https://www.interserver.net/tips/kb/cookies-vs-localstorage-vs-sessionstorage-what-each-one-exactly-means/?utm_source=openai