Как реализована авторизация на проекте

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

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

Как отвечать

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

Частые варианты и что в них проверять:

• сессия с cookie: флаги HttpOnly, Secure, SameSite, смена идентификатора сессии после входа, реальное завершение сессии на сервере при выходе, защита от CSRF;
• JWT: срок жизни access-токена, работа refresh-токена, отказ при изменённой подписи, при alg: none, при просроченном exp. Плюс вопрос, как отзываются токены при смене пароля;
• OAuth 2.0 и OpenID Connect: корректный redirect_uri, параметр state, поведение при отказе пользователя на экране согласия;
• ролевая модель: матрица «роль × действие», по которой проверяется каждый эндпоинт, а не только видимость кнопок в интерфейсе.

Инструменты: Postman или Bruno для запросов с разными токенами, Burp Suite для подмены параметров, автотесты API на pytest или REST Assured.

Отдельно назовите проверку IDOR: пользователь А подставляет в запрос идентификатор заказа пользователя Б. Это одна из самых частых реальных уязвимостей, в OWASP Top 10 она относится к категории Broken Access Control.

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

Путают 401 и 403. Первый означает «не аутентифицирован», второй «аутентифицирован, но нельзя».

Проверяют права только через интерфейс. Спрятанная кнопка не защищает эндпоинт, прямой запрос часто проходит.

Говорят, что пароли в базе «зашифрованы». Их хешируют медленной функцией вроде bcrypt или Argon2, и расшифровать хеш нельзя в принципе.