Что такое куки и как они передаются в HTTP-запросах
Что проверяют
Умеете ли вы читать сетевую вкладку и понимать, почему запрос ушёл без авторизации. Для тестировщика это вопрос про воспроизведение сценариев руками, про проверки на уровне API и про баги, которые видны только в заголовках.
Как отвечать
Сервер выставляет куку заголовком Set-Cookie в ответе, браузер сохраняет её и в следующих запросах на подходящий адрес сам добавляет заголовок Cookie. Ключевая деталь: назад уходят только пары имени и значения, без Expires, Path и флагов, поэтому атрибуты смотрят в ответе или в хранилище браузера, а не в запросе.
Что браузер учитывает при отправке: домен и поддомены по Domain, префикс пути по Path, срок жизни по Expires или Max-Age (без них кука сессионная), Secure (только по защищённому соединению), SameSite (уйдёт ли кука вместе с запросом, начатым с чужого сайта), HttpOnly (скрипту она не видна, но в запрос попадёт).
Что из этого проверяет тестировщик: выставлены ли флаги на сессионной куке, меняется ли идентификатор после входа, перестаёт ли старое значение работать после выхода, не живёт ли кука дольше заявленного срока, не утекает ли она на соседние поддомены.
Где спотыкаются
Ищут атрибуты в запросе и делают вывод, что флаги не выставлены. В запросе их нет по устройству протокола: HttpOnly и Secure проверяют в ответе или в таблице хранилища.
Проверяют выход из системы по исчезновению куки в браузере. Это проверка клиента, а не сервера. Сильная проверка иная: сохранить значение, нажать выход, подставить прежнюю куку в запрос вручную и убедиться, что сервер отвечает отказом.
Гоняют сценарии инструментом, который сам подставляет куки, и не замечают, что приложение авторизуется иначе. Стоит хотя бы раз собрать запрос без автоматической подстановки и посмотреть, что реально требуется: кука, заголовок с токеном или оба сразу.