Cookies, local storage, кэш и отпечаток браузера: в чём разница

Эти понятия часто встречаются вместе в настройках приватности, инструкциях по отладке и продуктах для управления профилями. Однако различия между ними достаточно велики, чтобы фраза «очистите браузер» была неполной инструкцией.

Как устроены основные механизмы

Механизм	Кто создаёт или контролирует	Обычная область действия	Типичная задача	Отправляется с запросом автоматически?
HTTP cookie	Сервер задаёт, браузер хранит и возвращает по правилам области действия	Узел или домен, путь, срок и условия соединения	Идентификаторы сеанса, настройки, состояние защиты от злоупотреблений	Да, если запрос соответствует области действия
localStorage	JavaScript сайта	Origin с учётом разделения хранилищ и политик браузера	Постоянное состояние приложения в парах «ключ — значение»	Нет
sessionStorage	JavaScript сайта	Origin в рамках сеанса просмотра верхнего уровня	Временное состояние вкладки или процесса	Нет
HTTP-кэш	Браузер и правила HTTP-кэширования	Ключ кэша, директивы ответа, политика браузера	Повторное использование ответов для снижения задержки и трафика	Может удовлетворить запрос или проверить актуальность ответа
Cache Storage API	JavaScript сайта или service worker	Origin или раздел хранилища	Офлайн-ресурсы и ответы под управлением приложения	Автоматически не прикрепляется; использование определяет скрипт
Отпечаток браузера	Сайт или другой наблюдатель измеряет сигналы	Зависит от наблюдателя и сигналов	Безопасность, выявление мошенничества, аналитика или отслеживание	Часть сигналов видна в запросах, для других нужен исполняемый код

Первые пять строк относятся к сохранённому состоянию. Последняя — к наблюдению и сопоставлению, хотя сохранённое состояние тоже может быть одним из входных данных.

Cookies: состояние для сервера с правилами области действия

Сам HTTP в основном не сохраняет состояние. Cookies позволяют серверу передать браузеру пару «имя — значение» и получать её в последующих подходящих запросах. RFC 6265 определяет заголовок ответа Set-Cookie, заголовок запроса Cookie и модель хранения браузера.

Cookie может быть:

• сеансовой — храниться до окончания сеанса, определяемого браузером;
• постоянной — иметь дату истечения или максимальный срок;
• привязанной к узлу — возвращаться только установившему её узлу;
• привязанной к домену — подходить указанному домену и соответствующим поддоменам;
• ограниченной путём — возвращаться только для подходящих путей запроса;
• Secure — передаваться только по защищённому каналу в понимании браузера;
• HttpOnly — быть недоступной через cookie-API для скриптов, оставаясь доступной HTTP-запросам.

Атрибуты влияют на отправку и доступ скриптов. Они не превращают значение cookie в самостоятельную границу безопасности. RFC 6265 прямо предупреждает, что на атрибут Path нельзя полагаться для защиты, и рекомендует защищённый транспорт и дополнительные меры для чувствительного содержимого cookies.

Почему удаление cookies выводит из аккаунта

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

По этой же причине копирование аутентификационных cookies чувствительно. Пригодный идентификатор сеанса может действовать как учётные данные. Не вставляйте исходные cookies в заявки, журналы, вывод автоматизации или командный чат.

Local storage: состояние одного origin под управлением скриптов

Стандарт HTML определяет localStorage как доступ к локальному хранилищу origin. Оно рассчитано на использование между окнами и сохранение после текущего сеанса. Хранилище содержит строковые пары «ключ — значение» и доступно скриптам с правами этого origin.

Origin обычно состоит из схемы, узла и порта. Поэтому следующие адреса имеют разные области хранения:

• https://app.example.test
• http://app.example.test
• https://admin.example.test
• https://app.example.test:8443

Путь URL не входит в origin. Страницы /billing/ и /support/ одного origin могут обращаться к одной области local storage, если приложение не создаёт собственное логическое разделение.

В отличие от cookie, запись localStorage не прикрепляется к HTTP-запросу автоматически. Скрипт сайта должен прочитать её и решить, что делать. Это удобно для настроек интерфейса, черновиков и данных приложения, но любой скрипт с полномочиями этого origin потенциально может получить к ним доступ. При работе с чувствительными сеансами учитывайте компрометацию скриптов: слово «локальное» не означает «секретное».

Постоянство здесь означает возможность пережить сеанс браузера, а не бессрочное хранение. Человек может очистить данные, политика — ограничить их, а браузер — применить правила хранения и вытеснения.

У sessionStorage другой срок жизни

sessionStorage связано с origin и сеансом просмотра верхнего уровня. Оно подходит для состояния, которое должно сохраняться, пока продолжается работа во вкладке или окне, и завершаться вместе с этим сеансом. У клонирования и восстановления вкладок есть зависящие от браузера особенности, поэтому не стоит делать это хранилище единственной записью критичной работы.

Local storage — лишь один механизм данных сайта

Современное веб-приложение также может хранить данные в IndexedDB, Cache Storage, регистрациях service workers, Origin Private File System, разрешениях и других хранилищах браузера. Очистка одного localStorage в инструментах разработчика поэтому может оставить другое состояние нетронутым.

Рекомендации стандарта HTML по приватности советуют браузерам давать возможность совместно очищать постоянные хранилища: иначе сайт может использовать одно из них для восстановления идентификатора, удалённого из другого.

Кэш: одно слово для нескольких механизмов

HTTP-кэш

RFC 9111 определяет HTTP-кэш как хранилище ответов и систему управления их сохранением, получением и удалением. Браузер может повторно использовать свежий ответ или проверить устаревший, уменьшая задержку и сетевой обмен.

Ключ кэша включает как минимум метод запроса и целевой URI, а заголовки ответа влияют на допустимость и срок повторного использования. HTTP-кэш — средство оптимизации. Наличие закэшированного изображения или скрипта обычно не означает, что пользователь вошёл в аккаунт.

Кэш всё же может влиять на приватность. В некоторых моделях угроз сведения раскрывают время ответа или наличие ресурса в кэше. Руководство W3C по фингерпринтингу включает наблюдение за закэшированными ресурсами среди способов делать выводы о конфигурации браузера или пользователя.

Cache Storage и service workers

Cache Storage API даёт сайту явные объекты Cache, управляемые скриптами, часто для офлайн-приложений. Спецификация Service Workers указывает, что эти кэши отделены от HTTP-кэша браузера, изолированы по origin и обновляются или удаляются логикой приложения, а не обычными правилами свежести HTTP.

Для отладки различие существенно:

• очистка «изображений и файлов в кэше» затрагивает обычный браузерный кэш;
• очистка данных сайта может также удалить Cache Storage и состояние service workers;
• перезагрузка с обходом HTTP-кэша может оставить активный service worker, продолжающий управлять запросами.

Перед проверкой или очисткой уточните, о каком именно кэше речь.

Разделение хранилищ добавляет ещё один ключ

Раньше область origin позволяла встроенному стороннему элементу читать одно хранилище внутри разных сайтов верхнего уровня. Современные браузеры всё чаще добавляют сайт верхнего уровня или связанный контекст в ключ хранилища.

Chrome документирует, что разделение хранилищ не позволяет фрейму example.com внутри a.com автоматически разделять Local Storage, IndexedDB, Cache Storage, service workers и некоторые механизмы связи с тем же фреймом внутри b.com. По документации Chrome это включено для всех пользователей начиная с Chrome 115, а отдельные дополнительные API изменялись позднее.

Так объясняется на первый взгляд странное поведение: один встроенный origin может видеть разные данные в зависимости от окружающего сайта. Но это не означает единую универсальную модель из двух ключей для всех хранилищ. Версия браузера, верхнеуровневый или встроенный контекст, предоставленный доступ к хранилищу, корпоративная политика, расширения и правила API могут менять результат.

Проверяйте точный контекст, а не делайте вывод только по домену.

Отпечаток браузера: наблюдаемые сигналы, а не папка

W3C определяет браузерный фингерпринтинг как возможность идентифицировать или повторно распознавать пользователя, пользовательский агент либо устройство по настройкам или другим наблюдаемым характеристикам. В руководстве 2025 года выделены несколько форм:

• Пассивный фингерпринтинг использует сведения, уже видимые в запросах или сети, например заголовки и IP-адрес.
• Активный фингерпринтинг исполняет код для наблюдения за размером окна, шрифтами, подключёнными устройствами, производительностью, датчиками или графическим рендерингом.
• Сопоставление кратковременных событий связывает контексты по почти одновременным изменениям устройства или среды.
• Механизмы, похожие на cookies, сохраняют и извлекают состояние способами, которые могут пережить обычные cookies или восстановить их.

Отпечаток редко является одним неизменяемым значением внутри браузера. Наблюдатель выбирает сигналы, объединяет их и оценивает сходство с предыдущим посещением. Результат может меняться после обновления браузера, изменения окна, установки шрифтов, подключения устройства или смены маршрута. Он может остаться похожим и после очистки cookies, поскольку многие исходные сигналы не изменились.

Фингерпринтинг не доказывает личность

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

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

Что меняют распространённые способы очистки

Действие	Вероятный результат	Что важно помнить
Удалить cookies сайта	Удаляются подходящие cookies браузера, часто профиль выходит из аккаунта	Серверные данные, другие устройства и хранилища помимо cookies могут сохраниться
Удалить cookies и другие данные сайтов	В зависимости от интерфейса и области могут удалиться cookies, Web Storage, IndexedDB, service workers и связанное состояние	Менеджер паролей, скачанные файлы, данные аккаунта и признаки устройства существуют отдельно
Удалить изображения и файлы в кэше	Удаляется содержимое обычного кэша ответов	Cookies, local storage и Cache Storage могут требовать отдельного выбора
Очистить историю	Удаляются посещённые URL и связанные подсказки в выбранной области	Скачанные файлы и записи на стороне сайта остаются
Удалить профиль браузера	С устройства удаляются его локальные закладки, история, пароли и другие настройки	Могут остаться синхронизированные данные, скачанные и экспортированные файлы, резервные копии и серверные данные
Создать новый профиль	Начинается новый набор состояния профиля	Устройство, ОС, сборка браузера и сеть могут оставаться наблюдаемо связанными

Справка Chrome об очистке разделяет историю, cookies и другие данные сайтов, кэш изображений и файлов, историю загрузок, автозаполнение, настройки сайтов и данные размещённых приложений. Она также указывает, что удаление истории загрузок оставляет файлы на компьютере, а удаление данных при выполненном входе может затронуть аккаунт Google и другие синхронизированные устройства.

Точный результат зависит от выбранного периода, профиля, состояния аккаунта, версии браузера и корпоративной политики. Прочитайте подтверждение перед удалением того, что трудно восстановить.

Как отдельные профили влияют на каждый механизм

У корректно разделённого постоянного профиля должны быть собственные cookies, веб-хранилища, базы сайтов, Cache Storage, принадлежащий ему HTTP-кэш, история, разрешения и состояние расширений. Это не даёт профилю B просто унаследовать сохранённый сеанс A.

Но общими могут оставаться:

• движок и версия браузера;
• ОС и оборудование;
• системные шрифты и параметры экрана;
• унаследованные от устройства язык, часовой пояс или настройки доступности;
• IP-адрес и сетевой путь без отдельного маршрута;
• поведение исполнителя или входы, связывающие действия на уровне приложения.

Разные профили могут и раскрывать разные сигналы из-за расширений, разрешений, размеров окон, языков или прокси. Итог зависит от реализации и контекста. Разделение профилей нужно оценивать как изоляцию состояния, а не как гарантию отпечатка.

Сначала определите симптом, затем очищайте данные

«Меня вывело из аккаунта»

Начните с cookies. Cookie сеанса могла истечь, быть удалена, отклонена политикой браузера или стать недействительной на сервере. Local storage может поддерживать интерфейс, но обычно не является cookie, автоматически отправляемой для аутентификации HTTP-запроса.

«Сайт потерял черновик или офлайн-данные»

Проверьте local storage, IndexedDB, Cache Storage и состояние service worker. Уточните origin и то, открыта ли страница на верхнем уровне или встроена в другой сайт: разделение может менять доступное хранилище.

«Первая перезагрузка медленная»

Возможная причина — пустой или устаревший HTTP-кэш. Сеть, сервер и service worker могут давать тот же симптом, поэтому сначала зафиксируйте время запросов и состояние кэша.

«Сайт всё ещё узнаёт среду после очистки»

Остаётся несколько объяснений: аккаунт авторизован в другом месте, сервер связал посещение по аккаунту или сети, другое хранилище сохранилось либо наблюдаемые характеристики позволили сопоставить сеансы. Фингерпринтинг — одна гипотеза, а не автоматический ответ.

Выбирайте действие по механизму

• Проверяйте или очищайте cookies, когда вопрос связан с серверными сеансами.
• Проверяйте хранилища origin, когда приложение сохраняет локальное состояние.
• Различайте HTTP-кэш и Cache Storage при диагностике устаревшего или офлайн-контента.
• Используйте отдельный постоянный профиль, когда рабочее состояние должно оставаться независимым.
• Рассматривайте фингерпринтинг как сопоставление наблюдаемых сигналов, чьи ограничения нельзя убрать очисткой или одной настройкой.

Такой подход помогает избежать двух дорогих ошибок: удаления лишнего состояния и предположения, что пустое хранилище cookies создаёт новую идентичность устройства.

Ограничения

Хранение и приватность меняются между браузерами и выпусками. Правила сторонних cookies, разделение хранилищ, вытеснение, синхронизация, корпоративные политики, расширения и приватные режимы могут менять описанное поведение. Статья объясняет стандарты и документацию Chrome на дату обращения к источникам, а не все реализации браузеров и сайтов.