Stage 7. Cookies
Cookie — это небольшой фрагмент состояния, который сервер передаёт браузеру, а браузер затем автоматически прикладывает к подходящим HTTP-запросам. На словах модель кажется простой, но в продакшене поведение cookie зависит от множества параметров: доменов, протокола, атрибутов безопасности, кросс-сайтовых сценариев и прокси-инфраструктуры.
Базовый жизненный цикл такой: сервер отправляет Set-Cookie, браузер сохраняет значение вместе с атрибутами, далее браузер решает, когда и куда эту cookie отправлять. Решение принимает не серверный код, а правила браузера. Поэтому даже идеально написанный backend может получить “пропавшую” cookie, если атрибуты заданы не в соответствии с фактическим окружением.
Set-Cookie: sid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax
Ключевые атрибуты нужно понимать на уровне причин и последствий. HttpOnly защищает от чтения cookie через JavaScript и снижает риск кражи при XSS. Secure запрещает отправку по HTTP и требует HTTPS. SameSite регулирует cross-site поведение и напрямую влияет на безопасность и UX в сценариях входа. Domain и Path определяют область действия cookie. Неверная комбинация этих параметров — типичная причина “авторизация иногда исчезает”.
Отдельная ловушка — удаление cookie. Браузер удаляет запись корректно только если параметры удаления совпадают с параметрами установки по области действия. Если при logout отправить другой Path или Domain, пользователь может увидеть “вы вышли”, но браузер продолжит отправлять старую cookie.
Set-Cookie: sid=; Path=/; Max-Age=0; HttpOnly; Secure; SameSite=Lax
Часто разработчики недооценивают, насколько cookie-зависимое поведение различается между локальной средой и production. Локально всё может работать на одном origin без HTTPS, но после деплоя появляются CDN, поддомены и реальные browser policy. Если команда не тестирует cookie-политику в production-like условиях, проблемы появляются уже у пользователей.
С точки зрения безопасности cookie не должна быть “контейнером для секретов”. Обычно в ней хранят короткий идентификатор сессии или технический токен, а чувствительные данные остаются на стороне сервера. Также важно маскировать значения cookie в логах, иначе утечки в observability-инфраструктуре становятся отдельным риском.
Хорошая практика — иметь единый внутренний стандарт cookie: какие атрибуты обязательны, какие TTL допустимы, как выполняется ротация, как делается удаление, что разрешено логировать. Такой документ резко снижает число повторяющихся инцидентов при росте команды.
Практический сценарий
Команда добавила logout, который возвращал Set-Cookie с Max-Age=0, но без исходного Path. В UI всё выглядело корректно, однако часть пользователей оставалась “призрачно залогиненной”. Причина оказалась в том, что браузер сохранял старую cookie под прежним путём. После симметричной настройки установки и удаления проблема исчезла. Этот пример показывает: в cookie-модели мелкие детали атрибутов определяют реальное поведение системы.