Какие проверки можно сгенерировать для авторизованного состояния в приложении?

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

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

Как отвечать

Проверки авторизованного состояния:

• жизнь сессии: вход сохраняется после перезагрузки, в новой вкладке, после перезапуска приложения при «запомнить меня». Истёкшая сессия ведёт на вход с возвратом на исходную страницу, обновление токена идёт незаметно;
• выход: после выхода старый токен отклоняет сервер, а не просто удаляет клиент. Кнопка «Назад» не показывает закрытые данные из кеша;
• параллельные сессии: вход с другого устройства, смена пароля завершает остальные сессии, блокировка админом выкидывает пользователя сразу;
• права: пользователь видит только свои пункты меню, прямой URL к админке даёт 403 или редирект. Главное: запрос к API с токеном одного пользователя к ресурсу другого по его id отклоняется. Это проверка на IDOR, интерфейс её не заменяет;
• изоляция данных: после смены аккаунта на том же устройстве не остаётся данных прошлого пользователя в кеше и localStorage;
• хранение токена: cookie с флагами HttpOnly, Secure и SameSite, токен не попадает в URL и логи.

Для автотестов: логин один раз через API или в setup-проекте, сохранение состояния и переиспользование. В Playwright это storageState, в Cypress cy.session(). На каждую роль свой аккаунт, а права удобно проверять матрицей «роль × действие».

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

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

Проверяют права только в интерфейсе. Кнопка скрыта, но API принимает тот же запрос, и уязвимость остаётся.

В параллельных автотестах используют один аккаунт. Один тест меняет настройки профиля, соседний падает, и прогон становится нестабильным.