🟥 Как тестировать авторизацию и не ограничиться «логин работает»

90% уязвимостей и прод-багов в авторизации — не в форме логина, а в управлении сессией и ролями.

Разбираем, что обязан проверить тестировщик:

1️⃣ Роли и доступы

Проверяем не только вход, а что доступно после входа:

— пользователь
— модератор
— админ
— заблокированный аккаунт

Важно:

🔜 Можно ли попасть в админку по прямой ссылке?
🔜 Меняется ли доступ при смене роли?
🔜 Есть ли IDOR (подмена ID в запросах)?

Авторизация = контроль доступа, а не просто логин.

2️⃣ Истечение сессии

Проверить:

— что происходит через 5 / 30 / 60 минут бездействия
— разлогинивает ли при истечении токена
— можно ли выполнить запрос с просроченным токеном

Опасный сценарий: UI разлогинил, а API продолжает принимать старый токен.

3️⃣ Повторный вход

Сценарии:

— логин с тем же аккаунтом в другом браузере
— логин после смены пароля
— логин после выхода

Проверить:
🔜 инвалидируется ли старая сессия
🔜 что происходит с активными вкладками

4️⃣ Параллельные сессии

Можно ли:

— быть залогиненным на 5 устройствах?
— ограничено ли количество сессий?
— что происходит при превышении лимита?

Для банковских и финтех-систем это критично.

5️⃣ Cookie и токены

Проверить:

— что будет после удаления cookie
— что будет при подмене токена
— флаги: HttpOnly, Secure, SameSite
— хранится ли JWT в localStorage (риск XSS)

Удалили cookie → система должна корректно считать вас гостем. Если нет — это уже уязвимость.

🔒 Почему это про безопасность

Ошибки в авторизации приводят к:

— захвату аккаунта
— повышению привилегий
— доступу к чужим данным
— обходу бизнес-ограничений

И именно тестировщик часто первый, кто это замечает.

📍 Навигация: [Вакансии]

🐸 Библиотека тестировщика

#карьерный_трек