Кратко

  • Проект HTTPbis описывает cookie как механизм хранения и возврата состояния, а не как единое доказательство личности, происхождения или полномочий.
  • Удаление по имени недостаточно: Domain и Path должны попасть в нужную область, а серверная сессия должна быть отозвана независимо от состояния браузера.
  • Expires и Max-Age задают верхнюю границу хранения, но не обещают, что браузер сохранит значение до этой даты.
  • Secure, HttpOnly и SameSite уменьшают разные риски, однако не подтверждают, кто установил значение, кому оно принадлежит и разрешено ли действие.

Удаляется область, а не просто имя

В модели cookie имя не существует само по себе. Хранилище различает записи с учётом доменной и путевой области, а также других атрибутов и времени создания. Поэтому ответ с тем же именем и истёкшим сроком не является универсальной командой «удалить всё». Он воздействует на запись, совпадающую с областью, которую описывает ответ.

Если приложение создало cookie для /account, а выход отправил истёкшее значение для /, результат может отличаться от намерения. Аналогичная ошибка возникает при различии между host-only записью и Domain-записью. На панели виден Set-Cookie с прошлой датой, тест отмечает HTTP 200, но нужная запись может продолжать жить и возвращаться на подходящих запросах.

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

Отзыв на сервере не должен ждать браузер

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

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

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

Срок действия — потолок, а не обещание хранения

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

Обратная ошибка столь же опасна: пока cookie присутствует, сессия якобы обязана оставаться действительной. На самом деле блокировка учётной записи, изменение роли, отзыв ключа, риск-сигнал или завершение работы оператора могут прекратить полномочие раньше клиентского срока. Две временные шкалы должны измеряться отдельно.

При расследовании фраза «cookie истекла» слишком широка. Возможны плановое достижение максимального возраста, раннее вытеснение, пользовательская очистка, ошибочное удаление другой области или серверный отзыв при сохранившемся клиентском значении. Каждая причина требует отдельного события и владельца.

Domain расширяет доставку, но не доверие

Host-only cookie ограничивается хостом, который её создал. Domain-атрибут может сделать запись пригодной для соответствующих поддоменов. Это удобно для тесно связанных сервисов, но оно не доказывает, что каждый соседний хост обладает одинаковой защитой, владельцем и цепочкой поставки.

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

Public Suffix List ограничивает опасные попытки распространить Domain слишком широко. Но она не решает вопрос доверия внутри зарегистрированного домена. Разные поддомены могут принадлежать разным командам, поставщикам или средам исполнения. Допустимая строка домена ещё не равна утверждённой границе безопасности.

Path помогает маршрутизации, а не изоляции

Path сужает набор запросов, к которым браузер прикрепит запись. Это полезная функция маршрутизации. Она не обещает целостность между независимыми приложениями на одном хосте и не превращает /admin и /shop в отдельные центры полномочий.

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

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

Secure доказывает защищённую доставку, не происхождение

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

Если соседний хост законно обслуживается по TLS и способен задать более широкую Domain-запись, оба транспортных участка могут быть защищены. Проблема происхождения всё равно остаётся. Канал ответил на вопрос, кому доставлен трафик; приложение ещё должно ответить, какой записи оно доверяет и почему.

Префиксы __Host- и __Secure- усиливают форму записи и полезны против некоторых ошибок и перезаписей. Но они не отменяют серверный срок, отзыв, привязку к контексту и авторизацию конкретного действия. Хорошая защита состоит из слоёв с известными остаточными рисками, а не из одного магического атрибута.

HttpOnly и SameSite ограничивают иные поверхности

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

SameSite управляет отправкой в межсайтовых контекстах. Он помогает против определённых классов атак, однако не является согласием пользователя, доказательством намерения или серверной авторизацией. Браузер классифицирует контекст запроса; бизнес-система должна отдельно оценить действие.

Когда панель объединяет Secure, HttpOnly и SameSite в зелёный знак «безопасная cookie», она скрывает разные утверждения. Полезнее показывать три выполненных ограничения и рядом — непроверенные вопросы: host-only ли запись, есть ли одноимённые области, отозвана ли сессия, соответствует ли пользователь и разрешено ли действие.

Порт не создаёт отдельное хранилище cookie

Модель web origin включает схему, хост и порт. Cookie не следует автоматически той же тройке как единой границе. Сервис на другом порту не должен считать, что состояние браузера отделено только номером порта.

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

Наблюдение должно доказывать результат

Журналы не должны хранить секреты. Достаточно хешированных имён и идентификаторов вместе с признаками host-only, Domain, Path, Secure, HttpOnly, SameSite, временем создания, потолком срока, исходным хостом, схемой и портом ответа, хостом и портом возврата, проверкой префикса и итогом серверной валидации.

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

Следует сигнализировать о Domain шире ожидаемого, одинаковых именах в нескольких областях, несоответствии Path или Domain при очистке, сессиях на неожиданных портах, раннем вытеснении, небезопасном пути установки и принятии идентификатора после отзыва. Эти события показывают механизм, а не только симптом.

Источники и ограничения

Зафиксированный пакет включает редакцию 02 проекта HTTPbis и её статус, историю и ссылки Datatracker, рабочую группу HTTP, RFC 6265, запись 6265bis, семантику HTTP, TLS 1.3, определения origin и URL WHATWG, реестр полей HTTP IANA и Public Suffix List.

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

Источники