Как управлять временем жизни сессии кроме очистки

Что проверяют

Знаете ли вы механизмы, которые ограничивают жизнь сессии, кроме ручного выхода и удаления куки, и как их проверить, не сидя полчаса перед экраном. Следом обычно спрашивают, что должно происходить с сессиями после смены пароля.

Как отвечать

Разложите ответ по механизмам и к каждому добавьте, как тестировать:

• таймаут неактивности: сессия продлевается при каждом запросе и истекает после паузы. OWASP для чувствительных приложений называет порядок 2-5 минут, для приложений с низким риском 15-30. Проверка: запрос сразу после порога получает 401 или редирект на вход;
• абсолютный таймаут: сессия заканчивается через фиксированное время независимо от активности. Проверяется, что даже активный пользователь выходит по его истечении;
• пара токенов: короткий access token с полем exp и refresh token для продления. Проверьте ротацию: после обновления старый refresh token не принимается, а в хорошей реализации его повторное использование гасит всю цепочку;
• серверное хранилище: запись сессии в Redis с TTL, выход и смена пароля удаляют её. JWT до exp сам не отзывается, нужен список отозванных или короткий срок жизни;
• атрибуты куки: Max-Age или Expires против сессионной куки, плюс HttpOnly, Secure, SameSite. «Запомнить меня» даёт отдельную долгую сессию, её проверяют отдельно;
• события безопасности: смена пароля, роли или блокировка аккаунта завершают остальные сессии, а после входа идентификатор сессии меняется, иначе возможна фиксация сессии.

Чтобы не ждать реальное время, попросите вынести таймауты на тестовом стенде в конфиг и выставить секунды или подменяйте время на сервере. Запросы с просроченным токеном удобно гонять в Postman или через curl.

Где спотыкаются

Проверяют только интерфейс. Фронт показывает экран входа, а API продолжает принимать старый токен, поэтому истечение проверяют прямым запросом.

Путают удаление куки в браузере с завершением сессии. Скопированный заранее идентификатор после «выхода» всё ещё работает, если сервер сессию не удалил.

Не различают таймаут неактивности и абсолютный и тестируют один сценарий, считая, что покрыли оба.