Cookies в браузере — сессия, настройки и границы отслеживания

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

Cookie — небольшой фрагмент данных, который браузер сохраняет по заголовку Set-Cookie или через доступный скрипту API и затем отправляет при подходящих запросах. Cookie может нести идентификатор сессии, выбранный язык или техническую настройку. Но он не равен ни паролю, ни всей истории пользователя, ни всей веб-аналитике.

Когда браузер впервые обращается к сайту, сервер может ответить заголовком Set-Cookie. Браузер сохраняет значение вместе с условиями, при которых его можно отправлять. В следующем подходящем запросе он добавит заголовок Cookie.

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

Эта схема похожа на номерок в гардеробе, но только в одном важном месте: номерок помогает найти вещь, а не содержит её внутри. В веб-продукте номерок — идентификатор; реальное состояние и правила доступа остаются на стороне backend.

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

Cookie часто отвечает на вопрос «какую сессию продолжить», а не «какие данные о человеке хранит компания».

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

Domain и Path задают область отправки cookie. Без Domain cookie является host-only и не отправляется поддоменам; с допустимым Domain она охватывает это имя и его поддомены, а ведущая точка исторического вида .example.com игнорируется. Без Path браузер вычисляет путь по URL запроса, установившего cookie; Path влияет на отправку, но не является границей доступа или безопасности.

Expires или Max-Age ограничивает срок хранения, причём при наличии обоих приоритет имеет Max-Age. Без них cookie считается сессионной, однако восстановление сессии браузера может вернуть её после перезапуска. Поэтому закрытие окна нельзя использовать как серверное правило окончания авторизации.

Secure предписывает отправлять cookie только по защищённому соединению. Оно не заменяет HTTPS: HTTPS защищает канал, а Secure ограничивает, в каких запросах браузер приложит конкретное значение. HttpOnly запрещает чтение cookie через JavaScript API, но cookie всё равно прикладывается к подходящим запросам, в том числе инициированным скриптом. Поэтому флаг уменьшает риск кражи значения при XSS, но не мешает вредоносному коду действовать от имени открытой сессии.

SameSite управляет межсайтовой отправкой cookie. Современные браузеры часто применяют Lax, если атрибут не указан, но детали значения по умолчанию и переходные послабления зависят от клиента. Для SameSite=None современные браузеры требуют Secure. Выбор значения зависит от сценария входа, внешней оплаты, встраивания и других переходов: нельзя без проверки поставить один режим всем cookie и ожидать, что ничего не перестанет работать. SameSite не заменяет серверную защиту от CSRF и контроль прав.

Атрибуты cookie не делают сессию безопасной сами по себе: они задают границы, которые сервер и сценарий должны соблюдать.

Префиксы имён позволяют поддерживающему браузеру отклонить cookie с несовместимыми атрибутами. __Secure- требует установку из защищённого контекста и Secure; __Host- дополнительно запрещает Domain и требует Path=/, привязывая cookie к текущему host. Поддержка более новых __Http- и __Host-Http- требует отдельной проверки.

Partitioned включает раздельное хранилище cookie по верхнеуровневому сайту и требует Secure; этот механизм известен как CHIPS. Он не возвращает универсальный доступ к обычным third-party cookie и не гарантирует работу в старых браузерах. Для реального встраивания отдельно проверяют SameSite, браузерную поддержку и политику пользователя.

Для технической инвентаризации полезно разделять cookie по назначению, а не по тому, «хорошие» они или «следящие».

First-party cookie используется в контексте того же сайта, а third-party — в межсайтовом контексте встроенного ресурса. Браузеры и настройки пользователя по-разному блокируют, разделяют или временно разрешают такое хранилище; единого правила «third-party cookie уже не работают нигде» нет. Поэтому измерение нельзя проектировать на предположении, что любой идентификатор будет доступен всегда. Когда важна бизнес-метрика, нужно описать событие и его проверку отдельно; сами события разбираются в материале о Яндекс Метрике.

Cookie отправляется с подходящими HTTP-запросами, поэтому это не универсальное место для больших данных. Лимиты по размеру и числу cookie зависят от браузера, а большой набор добавляет трафик к запросам. Для клиентских данных, которые не должны автоматически уходить серверу, существуют localStorage, sessionStorage и другие механизмы браузера — но у них свои области доступа и риски. Они не превращаются в cookie и не получают HttpOnly.

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

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

Перед публикацией политики, настройкой согласий или подключением нового трекера нужен отдельный юридический фактчек применимых требований. Статья 6 152-ФЗ предусматривает несколько возможных условий обработки; согласие — одно из них, а не универсальное основание для любой cookie. Если для конкретной обработки выбрано согласие, его содержание и способ получения проверяют с учётом статьи 9; баннер или чекбокс не заменяет такую проверку. Эта статья не заменяет юриста.

Технический инвентарь должен фиксировать цель, владельца, состав и связь идентификаторов, получателей, срок, место и маршрут хранения. Принципы статьи 5 требуют соотносить объём и срок хранения с заявленной целью. Требование части 5 статьи 18 о базах данных в России применяется в своей установленной сфере при сборе персональных данных граждан РФ через интернет и содержит исключения; из одного факта установки cookie нельзя вывести готовое заключение о локализации.

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

Общий баннер не заменяет ответа на вопрос, зачем конкретная cookie существует в конкретном маршруте.

Откройте инструменты разработчика в браузере и не ограничивайтесь списком названий. Пройдите сценарии входа, выхода, корзины, формы и переключения языка; посмотрите, какие cookie появляются и исчезают.

Для приёмки сделайте не только снимок списка cookie. Проверьте, что после входа сессия сменяется, после выхода сервер перестаёт принимать прежний идентификатор, после удаления или истечения понятен пользовательский результат, а отказ от необязательной категории не запускает соответствующий сценарий. Отдельно пройдите оплату, переход с внешнего домена и встроенный виджет, если они есть: именно на этих маршрутах проявляются ошибки SameSite и third-party ограничений.

Cookies — небольшой, но важный механизм состояния в браузере. Он помогает продолжить сессию и сохранить полезную настройку, но требует точной настройки области, срока и атрибутов. Технический аудит начинается с инвентаризации назначений и проверки реальных маршрутов пользователя; затем для каждого сценария отдельно проверяют применимые правовые требования.

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