Теперь вы умеете проверять ответ API по четырём осям. Но прежде чем API вообще ответит данными, он должен понять, КТО делает запрос и ЧТО этому «кто» разрешено видеть. Это авторизация — и тестировщику важно уметь проверить её напрямую в Postman, не через интерфейс.
Чему научишься за этот урок:
— выполнять запрос от имени конкретного пользователя с помощью токена;
— проверять, что запрос без токена или с невалидным токеном корректно отклоняется;
— работать с тестовыми токенами в учебных окружениях, не раскрывая реальные секреты.
Токен и заголовок Authorization
Авторизация в API обычно передаётся через токен — строку, которая подтверждает, кто делает запрос. Токен передают в заголовке запроса: Authorization: Bearer <токен>. Сервер проверяет токен и по нему понимает, какому именно пользователю разрешён доступ и к каким данным.
Отличие аутентификации от авторизации уже разбирали в уроке 3.5 главы 3: аутентификация отвечает на вопрос «кто ты», авторизация — на вопрос «что тебе разрешено». Токен в заголовке Authorization — это именно про второе: сервер уже знает, кто вы (аутентификация прошла раньше, например при входе), и теперь по токену решает, что вам можно.
Два сценария проверки
Тестировщик проверяет два противоположных сценария. Сценарий (а): запрос С валидным токеном от имени конкретного пользователя — должен успешно выполниться и вернуть только то, что разрешено ИМЕННО этому пользователю, а не чужие данные. Сценарий (б): запрос БЕЗ токена или с невалидным токеном (истёкшим или поддельным) — должен быть ОТКЛОНЁН, обычно с кодом 401 Unauthorized (этот код вы уже разбирали в уроке про коды ответа в главе 3).
Безопасность: только тестовые секреты
В учебных и тестовых окружениях для проверки авторизации используют вымышленные тестовые токены и тестовые аккаунты, специально созданные для тестирования. Реальные боевые секреты — настоящие пароли, настоящие токены доступа к рабочим системам — НИКОГДА не должны попадать в тестовые скрипты, скриншоты или документацию. Это то же правило маскировки, что уже применялось в главе 3: cookies и токены на скриншотах DevTools закрывались символами ?, чтобы случайно не раскрыть реальный секрет.
Пример
Тестировщик отправляет GET /api/user/profile с валидным токеном пользователя Ивана — в ответе приходит именно профиль Ивана, а не чужой. Затем тестировщик убирает заголовок Authorization полностью и повторяет тот же запрос — ожидаемый результат: код 401, доступ отклонён.
Запрос 1: GET /api/user/profile + Authorization: Bearer <токен Ивана> -> 200, профиль Ивана Запрос 2: GET /api/user/profile без заголовка Authorization -> 401 Unauthorized
Итог:
— авторизация в API обычно передаётся токеном в заголовке Authorization: Bearer <токен>;
— сценарий (а) — валидный токен конкретного пользователя должен вернуть только разрешённые ЕМУ данные;
— сценарий (б) — запрос без токена или с невалидным токеном должен быть отклонён, обычно кодом 401 Unauthorized;
— в тестах используют только вымышленные тестовые токены и аккаунты, реальные боевые секреты в тестовые материалы не попадают никогда.
Контрольный вопрос. В каком заголовке запроса обычно передаётся токен авторизации?
Подсказка: Название заголовка прямо указывает на его назначение — авторизацию.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. На какой вопрос отвечает авторизация, в отличие от аутентификации?
Подсказка: Вспомни различие из урока 3.5 главы 3 — аутентификация про «кто ты», авторизация про другое.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какой код ответа обычно означает отказ в доступе из-за отсутствия или невалидности токена?
Подсказка: Этот код уже разбирали в главе 3 — он про то, что пользователь не авторизован.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Что должно попадать в тестовые скрипты, скриншоты и документацию при проверке авторизации?
Подсказка: В уроке прямо сказано, какое правило безопасности здесь действует — то же, что уже применялось в главе 3.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какие из утверждений про проверку авторизации API верны (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Сверь с правилом про боевые секреты из урока — одно утверждение прямо противоречит этому правилу.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Как называется заголовок запроса, в котором передаётся токен авторизации? Ответь одним словом по-английски, как в уроке.
Подсказка: Это название заголовка, о котором говорится в самом начале урока.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Тестировщик отправляет GET /api/user/profile без заголовка Authorization вовсе. Какой код ответа он должен получить, если сервер работает правильно? Ответь числом.
Подсказка: Это тот же код, который уже встречался в главе 3 для случая «не авторизован».
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Если сервер спроектирован правильно (см. ситуацию выше), определять личность пользователя он должен по тому, что передаётся в заголовке Authorization, — а не по производным данным, которые может прислать в теле запроса кто угодно. Как в API называется то, что передаётся в этом заголовке и доказывает личность? Ответь одним словом.
Два разных пользователя системы отправляют GET /api/user/profile. У одного в теле запроса случайно оказывается чужой ID вместо своего, но в заголовке Authorization у каждого передаётся своя собственная, настоящая строка, полученная при входе в систему.
Подсказка: Выдаётся при входе в систему и подтверждает «это точно я» — в отличие от текстовых полей внутри самого запроса, которые сервер сам по себе не проверяет на подлинность.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Объясни в 2-3 предложениях: почему в тестовых материалах (скриптах, скриншотах, документации) нельзя использовать реальные боевые токены доступа, даже если это удобнее, чем создавать отдельные тестовые аккаунты?
Критерий приёмки: объяснено, что реальный боевой токен — это действующий доступ к рабочей системе, и его утечка через тестовые материалы (скриншот, документ, скрипт в репозитории) создаёт риск безопасности для реальных пользователей и данных продукта; упомянуто правило маскировки секретов, уже применявшееся в главе 3.
Подсказка: Вспомни, что боевой токен — это не абстракция, а реальный работающий доступ к системе, если он утечёт.
✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.
Онлайн-проверка ответа появится позже
Задание. Тестировщик проверяет API интернет-магазина курсов. Он отправляет GET /api/orders/555 с валидным токеном пользователя Ивана — и получает в ответе заказ номер 555, который на самом деле принадлежит Марии, а не Ивану. Код ответа при этом 200. Это баг или ожидаемое поведение? Если баг — на какую сторону, аутентификацию или авторизацию, он указывает? Обоснуй в 2-3 предложениях.
Критерий приёмки: названо, что это баг; аутентификация здесь явно работает (сервер верно узнал, что это Иван, по его токену), а вот авторизация нарушена — сервер не проверил, что заказ 555 принадлежит именно этому пользователю, и выдал чужие данные. Указано, что код 200 маскирует проблему — формально запрос «успешен», но по сути произошла утечка чужих данных.
Подсказка: Токен верно опознал пользователя (Ивана) — вопрос в том, должен ли был Иван вообще увидеть ИМЕННО этот заказ.
✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.
Онлайн-проверка ответа появится позже
Что дальше
Вы умеете проверять доступ конкретного пользователя и отказ без токена. Но что если сам API принимает заведомо некорректные данные, которые не должен принимать? В следующем, последнем уроке этой главы разберём негативные API-проверки и то, как по ответу API отличить дефект на стороне клиента от дефекта на стороне сервера.
