Авторизация в API: токены, сессии и что проверять тестировщику
Дефекты авторизации — самые дорогие из всех: они не ломают интерфейс, но открывают чужие данные. Разберём, как устроен доступ и что проверять в первую очередь.
Два разных слова, которые постоянно путают
Аутентификация — кто вы. Проверка логина и пароля, кода из письма, входа через Telegram.
Авторизация — что вам можно. Проверка прав уже опознанного пользователя.
Разница практическая: 401 означает «не представились», 403 — «представились, но нельзя». Если сервер на чужой ресурс отдаёт 401 вместо 403, это уже подсказка о том, что проверки прав нет вовсе.
Способы, которые встречаются на практике
| Способ | Как выглядит | Где применяется |
|---|---|---|
| Сессия в cookie | Cookie с идентификатором сессии | Классические веб-приложения |
| Bearer-токен | Authorization: Bearer eyJ… | Большинство современных API |
| API-ключ | X-Api-Key: abc123 | Интеграции между сервисами |
| Basic | Authorization: Basic base64 | Внутренние и служебные интерфейсы |
| OAuth 2.0 | Обмен кодом на токен через провайдера | Вход через сторонние сервисы |
Чаще всего вы встретите Bearer-токен. Обычно это JWT — строка из трёх частей через точку: заголовок, данные, подпись. Первые две части закодированы, но не зашифрованы: их может прочитать кто угодно.
Возьмите JWT из запроса и раскодируйте среднюю часть (это обычный base64). Если внутри оказались персональные данные, внутренние идентификаторы или что-то чувствительное — это дефект: содержимое токена доступно любому, кто его получил.
Что проверять обязательно
- Запрос без токена. Ожидается 401. Если данные вернулись — метод открыт всем, это критично.
- Испорченный токен. Поменяйте один символ: ожидается 401, а не 500.
- Истёкший токен. Дождитесь или подставьте старый: должен быть отказ и понятное поведение интерфейса.
- Чужой ресурс. Подставьте идентификатор другого пользователя — 403 или 404, но не данные.
- Токен другой роли. Обычный пользователь дёргает административный метод — отказ.
- Токен после выхода. Вышли из аккаунта, повторили запрос со старым токеном: должен перестать работать.
- Смена пароля. После смены старые токены и сессии в идеале должны отзываться.
Четвёртый пункт — самый результативный. Проверяется за минуту, а находит уязвимость, из-за которой любой пользователь читает чужие данные, просто меняя цифру в адресе.
Где живут дефекты
- Права проверяются только на клиенте. Кнопки в интерфейсе спрятаны, а метод доступен всем — классика.
- Проверка есть на одном методе и нет на соседнем. Чтение защищено, а удаление забыли.
- Токен в адресе страницы. Он попадает в логи, историю браузера и в заголовок Referer при переходе на другой сайт.
- Бесконечный срок жизни. Украденный токен работает вечно.
- Нет ограничения на попытки входа. Пароль подбирается перебором.
- Разные ответы для существующего и несуществующего пользователя. Форма превращается в способ проверить, зарегистрирован ли человек.
Как удобно проверять
Постоянно логиниться руками — самая скучная часть. В Postman это автоматизируется: запрос авторизации первым в коллекции, во вкладке Tests две строки кладут токен в переменную окружения, все остальные запросы берут его оттуда.
Дальше заводите второй набор переменных — для пользователя с другой ролью. Переключение окружения превращает проверку прав из отдельной задачи в один клик. Как это настроить — в разборе Postman для тестировщика.
Матрица прав: как не проверять наугад
Когда ролей больше двух, проверять «на глаз» бесполезно: часть сочетаний обязательно пропустится. Помогает простая таблица — роли по строкам, действия по столбцам.
| Действие | Гость | Пользователь | Владелец | Админ |
|---|---|---|---|---|
| Просмотр чужого заказа | 401 | 403 | — | 200 |
| Просмотр своего заказа | 401 | 200 | 200 | 200 |
| Изменение заказа | 401 | 403 | 200 | 200 |
| Удаление заказа | 401 | 403 | 403 | 200 |
Заполняя такую таблицу, вы почти всегда находите клетки, для которых в требованиях ответа нет. Например: может ли владелец удалить свой заказ после оплаты? А администратор — изменить чужой без ведома владельца?
Каждая пустая клетка — вопрос аналитику, а каждый неверный ответ сервера — дефект безопасности. Техника, которая помогает строить такие таблицы системно, разобрана в статье про таблицы решений.
OAuth: что нужно знать
Вход через сторонний сервис устроен так: приложение отправляет вас к провайдеру, вы там подтверждаете доступ, провайдер возвращает код, приложение обменивает код на токен. Пароль приложение не видит — в этом смысл.
Что проверять: отказ от подтверждения обрабатывается корректно; повторный вход не создаёт второй аккаунт; если почта у провайдера совпадает с существующим аккаунтом — что происходит, привязка или дубль; отзыв доступа на стороне провайдера приводит к отказу.
Что означает 401 и 403?
401 — не представились или представились неверно. 403 — представились, но прав недостаточно. Путаница между ними — частый дефект сама по себе.
Нужно ли тестировщику разбираться в JWT?
На уровне «из чего состоит и что данные внутри читаемы» — да. Проверять подпись вручную обычно не требуется.
Это же тестирование безопасности, разве им занимается обычный тестировщик?
Базовые проверки прав доступа — да, и это входит в обычную работу. Глубокий анализ уязвимостей — отдельная специализация, но подстановка чужого идентификатора доступна каждому.