Что происходит с сессией при принудительном закрытии браузера

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

Различаете ли вы сессию на сервере и куку в браузере, и умеете ли проверять завершение сессии не глазами, а запросом. Вопрос звучит бытово, но за ним целый класс дефектов безопасности: сессия, которая продолжает жить после того, как пользователь считает себя вышедшим.

Как отвечать

Разделите две сущности. В браузере лежит идентификатор, обычно в куке без срока жизни: такая кука считается сессионной и пропадает при закрытии браузера. На сервере лежит сама запись о сессии, и закрытие браузера её никак не трогает, она живёт до истечения таймаута бездействия или абсолютного срока.

Отсюда практический вывод: пользователь выглядит разлогиненным, потому что потерял идентификатор, а сессия при этом ещё действительна. Если значение куки кто-то успел скопировать, вход по нему продолжит работать.

Что проверять тестировщику:

• атрибуты в Set-Cookie: срок жизни, HttpOnly, Secure, SameSite;
• повтор старого значения куки консольным клиентом после закрытия браузера и отдельно после явного выхода, ожидаем отказ;
• таймаут бездействия и абсолютный срок, продлевается ли он на каждом запросе;
• что лежит в localStorage и sessionStorage: первое переживает закрытие окна, второе привязано к вкладке;
• поведение при восстановлении вкладок, когда браузер настроен продолжать с того же места.

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

Проверяют только через интерфейс. Открыли заново, увидели форму входа, записали как успех. Это ничего не доказывает: завершение сессии подтверждает лишь отказ сервера на старый идентификатор.

Путают потерю куки с завершением сессии и заводят обратный дефект: после закрытия пользователь остался залогинен. Чаще это не дефект, а либо восстановление вкладок браузером, либо честная кука с длинным сроком от галочки «запомнить меня».

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