Как передаются Cookies между клиентом и сервером

Механизм передачи Cookies между клиентом и сервером

Cookies — это небольшие фрагменты данных, которые сервер отправляет клиенту (обычно веб-браузеру) для хранения на стороне клиента и последующей автоматической передачи обратно на сервер с каждым новым запросом. Это фундаментальный механизм для поддержания состояния (stateful взаимодействия) в изначально stateless-протоколе HTTP.

Процесс передачи: пошаговый сценарий

Рассмотрим типичный поток на примере аутентификации пользователя:

1. Клиент отправляет запрос без Cookie (например, GET /login).

   GET /login HTTP/1.1
   Host: www.example.com
   User-Agent: Mozilla/5.0...
   

2. Сервер аутентифицирует пользователя (через форму) и в ответе устанавливает Cookie.

    Сервер включает в ответ заголовок `Set-Cookie` с данными сессии.

```http
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: sessionId=abc123xyz; Path=/; HttpOnly; Secure; SameSite=Strict
```

    *   `sessionId=abc123xyz` — пара **имя=значение**.
    *   `HttpOnly` — запрещает доступ к cookie через JavaScript (защита от XSS).
    *   `Secure` — передача cookie только по HTTPS.
    *   `SameSite=Strict` — регулирует отправку cookie с межсайтовыми запросами.

1. Браузер сохраняет Cookie. Он хранит имя, значение, атрибуты (домен, путь, срок жизни) и автоматически управляет сроком действия.

2. Клиент отправляет последующие запросы с Cookie.

    При каждом новом запросе к домену `www.example.com` браузер автоматически добавляет заголовок `Cookie`.

```http
GET /dashboard HTTP/1.1
Host: www.example.com
Cookie: sessionId=abc123xyz; userId=john_doe
User-Agent: Mozilla/5.0...
```

    Обратите внимание: все соответствующие cookie отправляются **в одной строке**, разделенные точкой с запятой.

1. Сервер получает и валидирует Cookie. Серверное приложение (например, бэкенд на Java/Python) извлекает значение sessionId из заголовка запроса, находит соответствующую сессию в своем хранилище (база данных, Redis) и идентифицирует пользователя.

Ключевые атрибуты Cookie, влияющие на передачу

• Domain & Path: Определяют scope cookie — к каким доменам и путям на сервере она будет прикрепляться. Cookie, установленная для .example.com, будет отправляться на все поддомены.
• Expires / Max-Age: Задают время жизни. Cookie с истекшим сроком удаляется браузером и не передается.
• Secure: Обязательное условие для передачи по HTTPS. При тестировании важно проверять, что критичные cookie (сессионные) имеют этот флаг в продакшн-среде.
• HttpOnly: Защитный флаг, исключающий кражу cookie через XSS-атаки. Проверка его наличия — обязательный пункт Security Testing.
• SameSite: Современный и критически важный атрибут для защиты от CSRF-атак и несанкционированных межсайтовых запросов.

    *   `Strict`: Cookie никогда не отправляется при межсайтовой навигации.
    *   `Lax`: (Значение по умолчанию в современных браузерах) Отправляется только при безопасных межсайтовых запросах (например, переход по ссылке).
    *   `None`: Cookie отправляется при любых кросс-доменных запросах (требует одновременной установки `Secure`).

Взгляд QA Engineer: на что обращать внимание при тестировании

1. Функциональное тестирование:

    *   После логина последующие запросы авторизованного пользователя должны содержать корректные cookie.
    *   Выход из системы (**logout**) должен приводить к инвалидации cookie на стороне сервера и отправке клиенту команды на удаление cookie (с `Set-Cookie` и прошедшим `Expires`).

1. Безопасность:

    *   **Обязательная** проверка наличия атрибутов `Secure` и `HttpOnly` у всех чувствительных cookie в production-среде.
    *   Проверка политики `SameSite`. Для API, используемых кросс-доменно, может потребоваться `SameSite=None; Secure`.
    *   Тестирование на уязвимость к **CSRF**: если `SameSite=Lax/Strict` не используется, необходимо убедиться в наличии дополнительных токенов (CSRF-token) в формах.

1. Инструменты для проверки:

    *   **Вкладка "Application/Storage" в DevTools браузера**: для просмотра сохраненных cookie, их значений и атрибутов.
    *   **Вкладка "Network"**: для анализа заголовков `Set-Cookie` в ответах сервера и `Cookie` в исходящих запросах.
    *   **Postman / Charles Proxy**: для ручного формирования запросов с/без cookie и детального анализа трафика.

1. Сценарии негативного тестирования:

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

Итог: Для QA Engineer понимание механизма передачи cookie — это не просто теория, а основа для построения эффективных тестов авторизации, безопасности сессий и кросс-доменного взаимодействия. Этот механизм лежит в основе логина, корзин покупок, персональных настроек и многих других функций современного веба.