Cookies, локальне сховище, кеш і цифровий відбиток браузера

Ці поняття часто згадуються разом у налаштуваннях приватності, інструкціях із налагодження та менеджерах профілів. Проте вони працюють по-різному, тому порада «очистити браузер» недостатньо точна.

Як розрізняти механізми

Механізм	Хто створює або контролює	Звичайна область дії	Типове призначення	Чи надсилається автоматично із запитом?
HTTP-cookie	Сервер встановлює, браузер зберігає й повертає за правилами	Хост або домен, шлях, строк дії та умови з’єднання	Ідентифікатори сеансів, налаштування, стан захисту від зловживань	Так, якщо запит відповідає області дії
localStorage	JavaScript сайту	Вебджерело з урахуванням розділення сховищ і політик	Постійний стан застосунку у форматі ключ–значення	Ні
sessionStorage	JavaScript сайту	Вебджерело в межах сеансу перегляду верхнього рівня	Тимчасовий стан вкладки або процесу	Ні
HTTP-кеш	Браузер і правила HTTP-кешування	Ключ кешу, директиви відповіді, політика браузера	Повторне використання відповідей для зменшення затримки й трафіку	Може задовольнити запит або перевірити актуальність відповіді
Cache Storage API	JavaScript сайту або service worker	Вебджерело чи розділ сховища	Офлайн-ресурси й відповіді, якими керує застосунок	Автоматично не додається; використання визначає скрипт
Цифровий відбиток браузера	Сайт або інший спостерігач вимірює сигнали	Залежить від спостерігача й сигналів	Безпека, протидія шахрайству, аналітика або відстеження	Частину сигналів видно в запитах, інші потребують виконання коду

Перші п’ять рядків стосуються збереженого стану. Останній — способу спостереження та зіставлення, хоча збережений стан також може бути одним із його джерел.

Cookies: стан для сервера з правилами надсилання

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

Cookie може бути:

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

Атрибути впливають на надсилання й доступ скриптів. Вони не роблять саме значення cookie самостійною межею безпеки. RFC 6265 прямо застерігає не покладатися на Path як на захист і рекомендує захищений транспорт та додатковий захист чутливого вмісту.

Чому видалення cookies завершує вхід

Багато сервісів зберігають випадковий ідентифікатор сеансу в cookie, а дані акаунта й самого сеансу — на сервері. Видалення cookie прибирає браузерну копію ідентифікатора, тому наступний запит більше не представляє той самий сеанс. Серверний акаунт та інші сеанси можуть залишитися.

Тому копіювання cookies автентифікації є чутливою операцією. Чинний ідентифікатор сеансу може діяти як обліковий секрет. Не вставляйте необроблені cookies у заявки, журнали, вивід автоматизації чи командні чати.

Локальне сховище: керований скриптами стан вебджерела

Стандарт HTML визначає localStorage як доступ до локальної області сховища вебджерела. Воно призначене для спільного використання між вікнами та збереження після поточного сеансу. У ньому зберігаються рядкові пари ключ–значення, доступні скриптам із правами цього джерела.

Вебджерело, або origin, зазвичай поєднує схему, хост і порт. Тому наведені адреси мають різні області сховища:

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

Шлях URL не входить до origin. Сторінки /billing/ і /support/ одного джерела можуть звертатися до того самого локального сховища, якщо застосунок сам не розділяє дані логічно.

На відміну від cookie, запис localStorage не додається до HTTP-запитів автоматично. Скрипт має прочитати його та визначити подальше використання. Це зручно для налаштувань інтерфейсу, чернеток і даних застосунку. Водночас будь-який скрипт із повноваженнями джерела потенційно має до нього доступ. Захист сеансів має враховувати компрометацію скриптів: «локальне» не означає «секретне».

Постійність тут означає можливість пережити сеанс перегляду, а не вічне зберігання. Людина може очистити дані, політика — обмежити їх, а браузер — застосувати квоти або правила видалення.

Інший строк життя sessionStorage

sessionStorage пов’язане з вебджерелом і сеансом перегляду верхнього рівня. Воно підходить для стану, який потрібен, поки триває робота у вкладці чи вікні, і має зникнути із завершенням сеансу. Клонування або відновлення вкладок має особливості в різних браузерах, тому це сховище не повинно бути єдиним записом критично важливої роботи.

Локальне сховище — лише один механізм даних сайту

Сучасні вебзастосунки також використовують 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-кешу, ізольовані за вебджерелом, а оновлення й видалення визначає логіка застосунку, не звичайні правила актуальності 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.

Так пояснюється несподіваний результат: те саме вбудоване джерело може бачити різні дані залежно від зовнішнього сайту. Але це не означає універсальної моделі з двома ключами для всіх сховищ. Результат залежить від версії, контексту верхнього рівня чи вбудовування, наданого доступу до сховища, корпоративних політик, розширень і правил API.

Перевіряйте конкретний контекст, а не робіть висновки лише за доменом.

Цифровий відбиток: спостережувані сигнали, а не папка

W3C визначає цифрове відбиткування браузера як можливість ідентифікувати або повторно впізнати користувача, браузер чи пристрій за налаштуваннями та іншими доступними характеристиками. У рекомендаціях 2025 року розрізняються:

• Пасивне відбиткування: інформація, уже видима в запитах чи мережі, наприклад заголовки та IP-адреса.
• Активне відбиткування: код вимірює розмір вікна, шрифти, підключені пристрої, продуктивність, датчики чи графічний рендеринг.
• Зіставлення короткочасних подій: контексти пов’язуються через майже одночасні зміни пристрою або середовища.
• Методи, подібні до cookies: збереження та читання стану через механізми, які можуть переживати звичайні cookies або відновлювати їх.

Відбиток рідко є одним незмінним значенням, яке браузер зберігає. Спостерігач вибирає сигнали, поєднує їх і оцінює подібність до попереднього відвідування. Результат може змінитися після оновлення браузера, зміни вікна, додавання шрифтів, підключення пристрою чи зміни маршруту. Він також може залишитися схожим після очищення cookies, бо базові характеристики не змінилися.

Відбиток не доводить особу

Набір сигналів може бути спільним для багатьох людей або змінюватися в однієї людини. Сайти можуть поєднувати його з входом, серверною історією акаунта, репутацією мережі чи збереженими ідентифікаторами. Тому впізнавання після очищення даних не доводить, що причиною був лише цифровий відбиток.

Так само зміна одного видимого параметра не гарантує нової ідентичності. Узгоджена поширена конфігурація може зменшувати окремі ознаки унікальності, а багато незвичних незалежних змін — створювати рідкісніше поєднання. Ці сигнали не дають підстав гарантувати невидимість або прийняття стороннім сервісом.

Що змінюють звичайні дії очищення

Дія	Імовірний ефект	Що може залишитися
Видалити cookies сайту	Видаляє відповідні cookies браузера й часто завершує вхід у цьому профілі	Дані акаунта на сервері, інші пристрої та сховища без cookies
Видалити cookies й інші дані сайтів	Залежно від браузера й вибраної області може видалити cookies, Web Storage, IndexedDB, service workers та інший стан	Менеджер паролів, завантажені файли, дані акаунта та спостережувані ознаки пристрою
Видалити кешовані зображення й файли	Видаляє звичайні кешовані відповіді	Cookies, localStorage і Cache Storage можуть потребувати окремого вибору
Очистити історію	Видаляє записи відвіданих URL та пов’язані підказки у вибраній області	Завантажені файли та записи на сайтах
Видалити профіль браузера	Видаляє з пристрою його локальні закладки, історію, паролі й налаштування	Синхронізовані дані, завантаження, експорт, резервні копії та серверні записи
Створити новий профіль	Починає інший набір стану профілю	Пристрій, ОС, збірка браузера та мережа можуть залишатися пов’язаними для спостерігача

Довідка Chrome про очищення розрізняє історію, cookies та інші дані сайтів, кешовані зображення й файли, історію завантажень, автозаповнення, налаштування сайтів і дані вебзастосунків. Вона також зазначає: очищення історії завантажень залишає файли на комп’ютері, а видалення даних після входу може впливати на Google-акаунт та інші синхронізовані пристрої.

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

Як окремі профілі впливають на ці механізми

Правильно розділений постійний профіль має власні cookies, вебсховища, бази даних сайтів, Cache Storage, HTTP-кеш, історію, дозволи та стан розширень. Це не дозволяє профілю B просто успадкувати збережений сеанс A.

Водночас спільними можуть залишатися:

• рушій і версія браузера;
• операційна система й обладнання;
• системні шрифти та характеристики екрана;
• мова, часовий пояс або налаштування доступності від системи;
• IP-адреса й мережевий шлях без окремого маршруту;
• поведінка оператора або входи, які пов’язують дії на рівні застосунку.

Профілі також можуть показувати різні сигнали через розширення, дозволи, розміри вікон, мови чи проксі. Загальний результат залежить від реалізації та контексту. Оцінюйте розділення як ізоляцію стану, а не гарантію певного відбитка.

Спочатку з’ясуйте симптом

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

Спершу перевірте cookies. Сеансова cookie могла завершити строк дії, бути видаленою, відхиленою політикою або знеціненою сервером. Локальне сховище може підтримувати інтерфейс, але зазвичай не є cookie, яку браузер автоматично надсилає для автентифікації HTTP-запиту.

«Сайт забув чернетку чи офлайн-дані»

Перевірте localStorage, IndexedDB, Cache Storage і стан service worker. Уточніть origin і те, чи сторінка відкрита самостійно або вбудована в інший сайт: розділення сховищ може змінювати доступні дані.

«Перше перезавантаження повільне»

Можлива причина — порожній або застарілий HTTP-кеш. Такий самий симптом спричиняють мережа, сервер і service worker, тому до висновку зафіксуйте час запитів і статус кешу.

«Після очищення сайт усе ще впізнає середовище»

Можливі різні пояснення: вхід зберігся деінде, сервер пов’язав відвідування за акаунтом або мережею, інше сховище пережило очищення чи спостережувані характеристики пов’язали сеанси. Цифровий відбиток — одна гіпотеза, а не автоматична відповідь.

Як вибрати дію

Виходьте з механізму:

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

Це допомагає уникнути двох дорогих помилок: видалити більше даних, ніж потрібно, і вирішити, що порожнє сховище cookies створює нову ідентичність пристрою.

Обмеження

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