Кто отвечает за создание и изменение куки в клиент-серверной архитектуре
Что проверяют
Понимаете ли вы механику: кто кладёт куку в браузер, кто её отправляет и кто может её поменять. Для тестировщика это основа проверок авторизации и сессий, поэтому следом спрашивают, как вы будете тестировать куку сессии и что увидите в DevTools.
Как отвечать
Создать и изменить куку могут две стороны, а хранит её всегда браузер:
- сервер: присылает в ответе заголовок
Set-Cookieс именем, значением и атрибутами. ПовторныйSet-Cookieс тем же именем,DomainиPathперезаписывает куку, аMax-Age=0или датаExpiresв прошлом удаляет её; - клиентский JavaScript: пишет через
document.cookieили через асинхронный Cookie Store API в современных браузерах. Куку с флагомHttpOnlyскрипт не видит и изменить не может; - браузер: хранит куки, сам подставляет подходящие в заголовок
Cookieкаждого запроса по домену и пути, удаляет просроченные и применяет свои ограничения, например блокировку сторонних кук.
Сразу назовите атрибуты, которые влияют на безопасность: HttpOnly (защита от кражи через XSS), Secure (только по HTTPS), SameSite (защита от CSRF, Chrome считает куку без этого атрибута как Lax), а также Domain, Path и срок жизни.
Потом переведите это в проверки. Вкладка Network показывает Set-Cookie в ответе и Cookie в запросе, вкладка Application даёт увидеть флаги и срок жизни. Типовые кейсы: у куки сессии стоят HttpOnly и Secure; после выхода сессия становится недействительной на сервере, а не только исчезает кука из браузера; подменённое вручную значение сервер отклоняет, а не принимает на веру.
Где спотыкаются
Отвечают «куки создаёт браузер». Он их хранит и отправляет, но решение о содержимом принимает сервер или скрипт страницы.
Проверяют только наличие куки и не смотрят атрибуты. Сессионная кука без HttpOnly это готовый баг безопасности, и найти его должен тестировщик.
Считают, что куку можно удалить по одному имени. Если Path или Domain не совпадают с теми, с которыми она создавалась, браузер считает это другой кукой, и старая остаётся на месте.