Почему заголовок Set-Cookie успешно установлен, но браузер не сохранил мой Cookie?
Это самая распространённая проблема: браузер не выдаёт ошибку активно, а просто тихо отклоняет не соответствующие требованиям Cookie. Частые причины: SameSite=None без Secure, Secure Cookie устанавливается с HTTP-страницы (кроме localhost), префиксы __Host-/__Secure- не удовлетворяют ограничениям, несоответствие Domain/Path, превышен лимит 4КБ, Max-Age равен 0 или отрицательный. Рекомендуется сначала вставить Set-Cookie в этот инструмент, чтобы определить конкретную причину по бейджам предупреждений, затем открыть Chrome DevTools → Application → Cookies, проверить под соответствующим доменом наличие жёлтого треугольника предупреждения — при наведении курсора вы увидите конкретную причину отклонения.
В чём разница между Strict, Lax и None для SameSite? Когда какое использовать?
Strict полностью запрещает межсайтовую отправку, самый безопасный вариант, но пользователь будет выглядеть неавторизованным при переходе по внешним ссылкам, подходит для Cookie чувствительных операций (платежи, смена пароля). Lax — значение по умолчанию в Chrome 80+, разрешает отправку при навигации GET верхнего уровня (переход по внешней ссылке на ваш сайт), но не отправляется в подресурсах iframe/img/script/XHR/POST-формах, является рекомендуемым значением для большинства сценариев. None разрешает отправку во всех межсайтовых сценариях (используется для единого входа SSO, сторонних встраиваний в iframe, межсайтовых вызовов API), но требует обязательной установки Secure, иначе браузер отклоняет напрямую.
Почему SameSite=None обязательно должен сопровождаться Secure?
Это правило, введённое Chrome начиная с версии 80 (февраль 2020), за которым последовали Firefox, Edge и Safari. Поскольку SameSite=None явно разрешает межсайтовую отправку Cookie, злоумышленникам проще проводить CSRF или подслушивание в межсайтовых сценариях, поэтому необходимо сопровождать Secure (зашифрованная передача по HTTPS) для снижения рисков. Если ваш SameSite=None Cookie устанавливается по HTTP, браузер отбросит его без сохранения. Этот инструмент обнаруживает комбинацию SameSite=None без Secure и помечает красным предупреждением.
Что использовать: Max-Age или Expires? В чём разница?
Предпочитайте Max-Age. Max-Age — относительное время (истекает через N секунд), не зависит от часов клиента, браузер начинает обратный отсчёт сразу после получения; Expires — абсолютный момент времени, зависит от локального времени компьютера пользователя (если пользователь переведёт часы на 1970 год, Cookie немедленно истечёт). При наличии обоих Max-Age имеет более высокий приоритет (чётко определено в RFC 6265). Если ни один не установлен, Cookie становится «сессионным Cookie», который истекает при закрытии браузера. Этот инструмент даёт подсказку, если Expires установлен, а Max-Age нет, рекомендуя добавить Max-Age. Обратите внимание, что единица измерения Max-Age — секунды, а не миллисекунды.
В чём разница между Path=/ и отсутствием настройки Path?
Path определяет, в каких URL-путях браузер будет отправлять этот Cookie в запросах. Если Path не установлен, браузер по умолчанию использует «путь URL ответа без последнего сегмента». Например, при установке Cookie из /api/user/login Path по умолчанию — /api/user/, поэтому в запросах путей / и /order/ этот Cookie отправляться не будет. Явная установка Path=/ делает Cookie действующим для всего сайта. Обратите внимание, что сопоставление Path — это сопоставление префикса: Path=/api также будет соответствовать /api/, /api/user, /api/v2/abc и т.д. Cookie с префиксом __Host- в обязательном порядке требуют Path=/.
В чём разница между Domain с точкой в начале (например .example.com) и без точки?
В современных браузерах (актуальные версии Chrome, Firefox, Edge, Safari) оба варианта уже эквивалентны: оба заставляют Cookie действовать для example.com и всех его поддоменов (a.example.com, b.c.example.com). Точка в начале — устаревший синтаксис времён RFC 2109, RFC 6265 чётко указывает, что начальная точка игнорируется. Тем не менее, для читаемости рекомендуется писать без точки. Этот инструмент даёт подсказку, если Domain начинается с точки (не ошибка, но устаревший синтаксис). Обратите внимание: без установленного Domain Cookie действует только для текущего хоста (поддомены не получают его), при установленном Domain начинает действовать для поддоменов.
Что такое префиксы __Host- и __Secure-? Можно ли работать без префиксов?
Это префиксы безопасности имён Cookie, введённые в RFC 6265bis для задания жёстких ограничений высокобезопасным Cookie: когда браузер видит, что имя Cookie начинается с __Host-, он в обязательном порядке требует установки Secure, Path=/ и отсутствия атрибута Domain — при невыполнении любого условия отклоняет сохранение напрямую; префикс __Secure- требует обязательной установки Secure, остальные атрибуты могут быть настроены. Работа без префиксов также возможна (большинство Cookie не используют префиксы), но для высокобезопасных Cookie, таких как идентификаторы сессии, токены авторизации, настоятельно рекомендуется использовать префикс __Host-, поскольку он предотвращает атаки внедрения Cookie на уровне поддоменов/путей. Этот инструмент автоматически проверяет соответствие обоих префиксов.
Действительно ли Cookie с HttpOnly безопасен? Защищает ли от XSS и CSRF?
HttpOnly запрещает JavaScript считывать значения Cookie через document.cookie, являясь важной линией обороны для <strong>снижения риска кражи сессии через XSS</strong>, но не является панацеей: XSS-злоумышленники всё равно могут выполнять запросы в браузере пользователя (запросы автоматически несут Cookie) для совершения действий (это сфера CSRF); HttpOnly также не защищает от CSRF-атак (требуется SameSite или CSRF Token). Только одновременное использование триады HttpOnly+Secure+SameSite=Lax/Strict обеспечивает базовый уровень безопасности. Чувствительные Cookie (session, JWT, access_token) обязательно должны быть HttpOnly, не давайте доступ к ним из фронтенд JS без необходимости. Этот инструмент помечает предупреждением Cookie без HttpOnly.
Что такое Partitioned (CHIPS) Cookie? Когда нужно использовать?
Partitioned — это новый атрибут, представленный Chrome в связи с отключением сторонних Cookie, полное название Cookies Having Independent Partitioned State (CHIPS). Традиционные сторонние Cookie (например, рекламы/встраиваемых сервисов, устанавливаемые на нескольких сайтах) являются глобально общими и могут использоваться для межсайтового отслеживания пользователей. С Partitioned браузер хранит сторонний Cookie отдельно для каждого сайта верхнего уровня: сторонний Cookie, который пользователь видит на Сайте А, полностью независим от того, что видит на Сайте Б, и не может разделять идентичность между сайтами. Сценарии использования: встроенные компоненты видео/карт/оплаты, сторонние плагины поддержки, межсайтовый SSO, встроенный в iframe. Использование Partitioned требует обязательной установки Secure, рекомендуется с префиксом __Host-.
Какой максимальный объём может хранить один Cookie? Сколько Cookie может быть на один домен?
Согласно RFC 6265, браузеры должны поддерживать как минимум 4096 байт на Cookie (включая имя, значение и атрибуты), основные браузеры (Chrome/Firefox/Safari/Edge) придерживаются этого лимита — содержимое сверх лимита усекается или отбрасывается тихо. Ограничения по количеству различаются в зависимости от браузера: Chrome — около 180 на домен, Firefox — около 150, Safari — около 600 (и подвержен влиянию политики семидневной очистки ITP); при превышении браузер удаляет самые старые Cookie по политике LRU. Рекомендуется хранить в Cookie только идентификаторы сессии, не помещайте в Cookie большие объёмы бизнес-данных (бизнес-данные размещайте в localStorage или серверной сессии).
Поддерживает ли инструмент копирование Set-Cookie напрямую из Chrome DevTools для анализа? Нужно ли вручную удалять префикс?
Полностью поддерживает, без необходимости ручной обработки. Вы можете нажать на целевой запрос в панели Network Chrome DevTools, кликнуть правой кнопкой мыши по значению Set-Cookie в области Response Headers, чтобы напрямую скопировать (для нескольких строк Ctrl/⌘+клик для множественного выбора или скопируйте весь блок) и вставить в область ввода этого инструмента. Инструмент автоматически удаляет префикс Set-Cookie: из начала каждой строки (без учёта регистра), автоматически обрабатывает пробельные символы в начале/конце строк, корректно обрабатывает специальные символы вроде запятых и точек с запятой в датах Expires, а также корректно обрабатывает значения Cookie в двойных кавычках.
Почему китайские или специальные символы в значениях Cookie становятся вида %XX?
RFC 6265 требует, чтобы значения Cookie использовали только безопасное подмножество набора символов ASCII, и не могут напрямую содержать не-ASCII символы, пробелы, запятые, точки с запятой и т.д. Многие серверные фреймворки при установке Cookie автоматически выполняют URL-кодировку (encodeURIComponent/Percent-encoding) для не-ASCII символов. Браузеры при отправке обратно также сохраняют закодированную форму. Когда этот инструмент обнаруживает, что значение содержит кодировку %XX, он автоматически отображает исходный текст, декодированный через decodeURIComponent рядом с исходным значением зелёной стрелкой, для удобства просмотра реального содержимого.
В чём разница между Set-Cookie и заголовком запроса Cookie?
Это заголовки совершенно разных направлений: Set-Cookie — заголовок ответа (сервер→браузер), появляется только в ответах, может встречаться несколько раз, каждый раз устанавливая один Cookie с полными атрибутами (Secure/HttpOnly/Path/Domain и т.д.); Cookie — заголовок запроса (браузер→сервер), появляется в запросе только один раз, содержит плоский список пар name=value всех Cookie, соответствующих текущей области действия (name1=v1; name2=v2), полностью без информации об атрибутах. То есть сервер не может знать из запроса, установлен ли у конкретного Cookie HttpOnly или Secure — информация об атрибутах сохраняется браузером только при локальном хранении. Для анализа заголовка Cookie в запросах используйте сопутствующий <a href='/network/http-cookie-parser/'>Анализатор заголовка запроса Cookie</a>.
Почему в Safari мои Cookie исчезают через несколько дней?
Это работает механизм интеллектуальной защиты от отслеживания Safari (ITP: Intelligent Tracking Prevention). Начиная с ITP 2.1, если пользователь не взаимодействует напрямую с доменом в течение 7 дней (то есть не посещал напрямую сайт этого домена), Safari очищает все Cookie и данные сайтов под этим доменом, независимо от того, насколько большой Max-Age/Expires установлены. Это в наибольшей степени затрагивает встроенные сторонние сервисы, в то время как Cookie основного сайта не затрагиваются, пока пользователь продолжает его посещать. Кроме того, ограничения Safari на сторонние Cookie строже чем у Chrome. Решения включают: использование атрибута Partitioned, запрос разрешения через Storage Access API или обновление Cookie при посещении пользователем основного сайта. Раздел устранения неполадок этого инструмента содержит более подробные указания по отладке в Safari.
Поддерживает ли инструмент пакетный анализ нескольких Set-Cookie? Отправляется ли содержимое Cookie на серверы?
Поддерживает пакетный анализ. Область ввода поддерживает вставку любого количества строк Set-Cookie (например, вставку сразу всего блока заголовков ответа), каждый Set-Cookie анализируется с независимой нумерацией, несколькими карточками атрибутов, отдельно отображающими атрибуты и предупреждения. Весь процесс анализа выполняется полностью локально в вашем браузере (чистая фронтенд-обработка JavaScript), содержимое Cookie не отправляется ни на какие серверы, не выполняется никаких сетевых запросов — чувствительная информация вроде Session/Token, которую вы вставляете, не покидает ваш компьютер, можно использовать спокойно.
