Cookie и устойчивость данных

Представь: ты пишешь сайт на PHP, и тебе нужно, чтобы данные пользователя не терялись после перезагрузки страницы. Или наоборот — чтобы они исчезали, как только закрылась вкладка. Тут в игру вступают Cookie, localStorage и sessionStorage. Но в чём их принципиальная разница? И главное — какой инструмент выбрать именно для твоей задачи?
Мы не будем читать лекцию про историю HTTP. Вместо этого — конкретное сравнение, таблица характеристик и честный разбор: кому Cookie подходят идеально, а кому лучше посмотреть в сторону Web Storage. Поехали.
1. Cookie: что это на самом деле и где подвох
Cookie — это небольшие текстовые файлы, которые сервер (PHP) отправляет браузеру, а браузер хранит их на диске пользователя. Размер одного Cookie — максимум 4 КБ. Срок жизни можно задать вручную (от секунды до года и более) или сделать сессионными — они умрут вместе с закрытием браузера.
Главная особенность: Cookie автоматически передаются на сервер с каждым HTTP-запросом. Это удобно для аутентификации (например, session_id в Cookie), но создаёт лишний трафик, если хранить там много данных. Ещё один нюанс — Cookie видны всем скриптам на домене, если не выставить флаг HttpOnly.
Пример на PHP: setcookie('user_pref', 'dark_theme', time() + 3600, '/'); — создаст Cookie на 1 час. Помни: без указания пути Cookie будет доступен только в текущей директории.
2. Альтернативы: localStorage и sessionStorage — чем они отличаются от Cookie
localStorage и sessionStorage — это часть Web Storage API. Они не отправляются на сервер автоматически, что снижает нагрузку. Размер хранилища — до 5–10 МБ (зависит от браузера). И это важно: если тебе нужно хранить, например, состояние корзины или настройки интерфейса — Web Storage выигрывает.
Разница между localStorage и sessionStorage простая: localStorage живёт вечно (пока пользователь не очистит кэш), а sessionStorage умирает, когда закрывается вкладка. Ни то, ни другое не передаётся на сервер — только через JavaScript.
Пример на JavaScript: localStorage.setItem('theme', 'dark'); — сохранит навсегда. sessionStorage.setItem('temp_data', 'value'); — только до закрытия вкладки.
3. Таблица сравнения: Cookie vs localStorage vs sessionStorage
Чтобы не запутаться, вот наглядное сравнение по ключевым параметрам. Смотри и выбирай свой вариант.
- Максимальный объём: Cookie — 4 КБ. localStorage — 5–10 МБ. sessionStorage — 5–10 МБ. Разница в 2500 раз — это критично для больших данных.
- Автоматическая отправка на сервер: Cookie — да, при каждом HTTP-запросе. localStorage/sessionStorage — нет, только через JS. Если хранишь много данных, Cookie могут замедлить сайт.
- Срок жизни: Cookie — настраивается через
expiresилиMax-Age. localStorage — до ручной очистки. sessionStorage — до закрытия вкладки. - Доступность: Cookie — все окна/вкладки одного домена. localStorage — все окна/вкладки одного домена. sessionStorage — только одна вкладка (даже если открыть тот же URL в новой вкладке — данные не будут общими).
- Безопасность: Cookie — уязвимы к XSS без HttpOnly, но есть флаг Secure (только HTTPS). localStorage — уязвим к XSS, защита только через JS. sessionStorage — уязвим к XSS, но данные живут недолго.
- Поддержка серверной логики: Cookie — поддерживается нативно (PHP, Node.js, любой бэкенд). localStorage/sessionStorage — только на клиенте, сервер не видит.
- Простота использования: Cookie — сложнее (нужно парсить строку, учитывать path/domain). localStorage — проще (ключ-значение). sessionStorage — то же самое, что localStorage.
4. Кому подходит Cookie, а кому — нет
Cookie — твой выбор, если:
- Нужно хранить идентификатор сессии (session_id) — это классика.
- Данные должны автоматически передаваться на сервер (например, в корзине интернет-магазина, где сервер должен знать содержимое).
- Работаешь с устаревшими браузерами (IE8-9), где Web Storage не поддерживается.
- Требуется, чтобы данные были доступны даже при отключённом JavaScript.
Cookie — не твой выбор, если:
- Хранишь много данных (больше 4 КБ) — используй localStorage.
- Данные чувствительны, и XSS-атака возможна — лучше комбинировать с серверной валидацией и HttpOnly.
- Нужно, чтобы данные не влияли на производительность (лишние заголовки при каждом запросе).
- Работаешь с SPA (React/Vue) — там Web Storage удобнее.
5. Практический пример: как выбрать на PHP
Допустим, ты пишешь интернет-магазин. Нужно хранить содержимое корзины. Если корзина большая (10+ товаров с описанием) — Cookie не подходит из-за лимита 4 КБ. Используй localStorage на клиенте, а на сервере — только ID товаров в сессии.
Если же тебе нужно хранить только количество товаров (например, 3 позиции) — Cookie справится. Пример на PHP: setcookie('cart_count', '3', time() + 86400, '/'); — сервер сможет прочитать это при следующем запросе.
Ещё один сценарий: сохранение темы оформления (светлая/тёмная). Это настройка, она не должна передаваться на сервер. Значит — localStorage. А если тема должна применяться сразу после загрузки страницы (без JS-фреймворков) — Cookie с флагом HttpOnly не подходит, нужен JS-доступ.
6. Безопасность и устойчивость данных: что важно знать
Cookie не защищены от перехвата, если не использовать HTTPS и флаг Secure. Всегда ставь Secure и HttpOnly, если данные не должны читаться через JS. Пример: setcookie('session_id', $sid, ['secure' => true, 'httponly' => true, 'samesite' => 'Strict']);.
localStorage и sessionStorage — не защищены от XSS вообще. Если злоумышленник внедрит скрипт на страницу, он прочитает всё, что лежит в хранилище. Никаких встроенных флагов безопасности там нет. Единственный способ — не хранить секретные данные (токены, пароли) в Web Storage. Для сессий — только Cookie с HttpOnly.
Устойчивость данных: Cookie могут быть удалены пользователем вручную или браузером (например, при очистке истории). localStorage живёт, пока его не удалят. sessionStorage — только для одной вкладки, и это может быть неожиданно: если пользователь откроет ссылку в новой вкладке, данные потеряются.
Вывод: для критичных данных (аутентификация) — Cookie с HttpOnly и Secure. Для остального — localStorage, если данные должны жить долго, или sessionStorage, если только на время сессии.
7. Итоговый алгоритм выбора на пальцах
Если ты не знаешь, что выбрать, пройди по этим трём вопросам:
- Данные должны быть доступны на сервере? Да → Cookie или серверная сессия (Cookie с session_id). Нет → переходи к вопросу 2.
- Объём данных больше 4 КБ? Да → localStorage (или sessionStorage, если только на вкладку). Нет → всё ещё можно Cookie, но подумай, нужно ли.
- Данные должны исчезать после закрытия браузера? Да → sessionStorage или сессионные Cookie (без
expires). Нет → localStorage или Cookie с большим сроком жизни.
Этот алгоритм сэкономит тебе кучу времени. Запомни его и применяй на практике.
Главное — не смешивай подходы без нужды. Если ты уже используешь Cookie для аутентификации, не пихай туда же настройки интерфейса — для них есть localStorage. Так и трафик меньше, и код чище.
Добавлено: 23.04.2026
