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

• что он уже авторизовался;
• какие товары добавил в корзину;
• какой язык выбрал;
• какую тему интерфейса использует;
• к какой группе A/B-теста он относится.

Здесь одним из механизмов являются Cookie

Cookie — это небольшой фрагмент данных, который сервер может попросить браузер сохранить и который браузер затем может отправлять серверу в последующих HTTP-запросах.
Можно представить Cookie как номерок в гардеробе.
Гардеробщик не обязан запоминать каждого посетителя лично. Он выдаёт номерок:
«Вот ваш номер — 123».
Когда посетитель возвращается, он показывает номерок:
«У меня 123».
По Cookie используется похожая логика:
браузер хранит значение → отправляет его серверу → сервер использует его для понимания контекста запроса.

Для системного аналитика особенно полезно знать несколько атрибутов.
Expires
Определяет дату, после которой Cookie перестаёт быть действительной.
Set-Cookie: session_id=abc123; Expires=Wed, 01 Oct 2026 12:00:00 GMT
Max-Age
Определяет время жизни Cookie в секундах.
Set-Cookie: session_id=abc123; Max-Age=3600
Здесь Cookie рассчитана на ограниченное время.
Secure
Cookie отправляется только по защищённому HTTPS-соединению.
Set-Cookie: session_id=abc123; Secure
Для чувствительных данных это важный параметр безопасности.
HttpOnly
Cookie с атрибутом HttpOnly недоступна JavaScript через стандартный механизм document.cookie.
Set-Cookie: session_id=abc123; HttpOnly
Это помогает снизить риск некоторых сценариев кражи Cookie через клиентский JavaScript.
SameSite
Определяет правила передачи Cookie в контексте межсайтовых запросов.
Основные значения:
Strict
Lax
None
Например:
Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Lax
SameSite особенно важен при:

• SSO;
• OAuth;
• интеграции нескольких веб-приложений;
• iframe;
• кросс-сайтовых сценариях.

Для системного аналитика полезно понимать, что Cookie можно анализировать не только в браузере.
Например, сервер возвращает:
HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; Path=/; HttpOnly
После этого следующий запрос может использовать:
GET /profile
Cookie: session_id=abc123
В Postman Cookie можно посмотреть и проверить отдельно.
Это удобно при тестировании:

• авторизации;
• пользовательских сессий;
• API;
• интеграций;
• различных сценариев доступа.

Особенно полезно сравнивать:
Browser → Request → Cookie → API
и
Postman → Request → Cookie → API
Если в Postman всё работает, а в браузере нет, это может быть сигналом проверить CORS, origin, SameSite, Secureи другие браузерные ограничения.

Упрощённо жизненный цикл можно представить так:
создание → сохранение → отправка → использование → обновление → удаление / истечение
Например:
Set-Cookie → Браузер сохраняет → Cookie отправляется → Сервер использует → Set-Cookie изменяет значение → Cookie истекает или удаляется

Cookie может исчезнуть:

• после окончания срока действия;
• при удалении пользователем;
• при удалении сайтом;
• в результате действий браузера;
• в некоторых случаях из-за настроек приватности или ограничений браузера.

Системному аналитику не обязательно становиться экспертом по внутреннему устройству браузера.
Но важно понимать роль Cookie в архитектуре системы.
Ключевая цепочка:
HTTP stateless → нужен механизм сохранения контекста → браузер хранит Cookie → Cookie отправляется с подходящими запросами → сервер использует её для реализации нужной бизнес- и технической логики.
И главное:
Cookie — механизм хранения и передачи данных браузером.
Session — состояние пользовательской сессии, часто хранящееся на сервере.
JWT — формат токена с claims, который может использоваться для аутентификации и авторизации.
CORS — механизм, связанный с контролем браузером cross-origin HTTP-взаимодействий.
Системному аналитику важно не просто знать термин Cookie, а понимать, как Cookie влияют на авторизацию, API, SSO, интеграции и поведение веб-приложения.