РУКОВОДСТВО 08 · ВЕБ-ПРИЛОЖЕНИЯ И API
Безопасность JWT: как проверить токены и отзыв доступа в своём API
Декодировать JWT — не значит подтвердить доверие к нему. Сервер проверяет подпись доверенным ключом, разрешённый алгоритм, ожидаемые claims и время, а затем отдельно решает вопрос доступа к объекту. Используйте тестовые токены и собственный issuer. На этой странице нет формы для отправки production-токенов.
Подготовить JWT-сценарииПонадобятся вход, подтверждение владения и согласие. Для авторизованных сценариев, мониторинга и CI нужен Pro или Business.
Содержание
Краткий ответ и условия проверки
Проверка JWT должна учитывать подпись, издателя, аудиторию и срок действия. Декодирование полей не является аутентификацией.
Короткоживущие тестовые токены и endpoint с описанными ожидаемыми правами.
| Проверка | Ожидаемое доказательство |
|---|---|
| Действие | Сравните действующий токен с истёкшим или с другой аудиторией; страница входа с HTTP 200 не означает успешный доступ к API. |
| Положительный и отрицательный контроль | Уязвимый пример даёт доказательство, исправленный — нет. Успешный контрольный запрос подтверждает доступность цели. |
| Блокировка или недостающие данные | Отметьте проверку как пропущенную или незавершённую с причиной. Отсутствие аккаунта, ответ WAF и таймаут не означают отсутствие проблем. |
| После исправления | Повторите проверку той же цели, аккаунта и объекта. Сохраните исходное доказательство и новый результат; покрытие ограничено выполненными сценариями. |
Продолжить: Посмотреть пример отчёта
Продолжить: Покрытие и необходимые данные
Декодирование подпись и авторизация
Декодирование читает данные, криптографическая проверка подтверждает подпись в заданной модели доверия, авторизация решает, что эта личность может делать. В обычном подписанном JWT payload не шифруется подписью. Поле role: admin, увиденное в декодере, ещё не является правом. В учебном тесте подпись корректна, но токен предназначен другому API: именно проверка audience должна остановить запрос.
Что задаётся на стороне сервера
На сервере заранее задайте допустимые алгоритмы, доверенный источник ключей, issuer, audience, тип токена и правила времени. Не берите доверенный URL ключей из непроверенного заголовка без собственной политики. Ожидания зависят от протокола приложения, поэтому не все claims обязательны одинаковым образом. Скачиваемая таблица помогает записать принятую политику, прежде чем запускать отрицательные сценарии.
claims = jwt.decode(token, key, algorithms=["HS256"],
audience="api-a", issuer="https://issuer.example",
options={"require": ["exp", "iss", "aud", "sub"]})
# Отдельно проверить право claims["sub"] на конкретный объект.Первичные источники: RFC 8725: JWT Best Current Practices · OWASP: Session Management
Продолжить: Проверка безопасности API с тестовыми аккаунтами
Тестовые отрицательные сценарии
Используйте тестовый issuer и известные ключи. Меняйте за один запрос одно условие: так отказ можно связать с конкретной проверкой.
Подпись, получатель и срок действия
Сначала отправьте рабочий тестовый токен. Затем отдельно проверьте повреждённую подпись, другой issuer, другой audience, истёкший срок и неизвестный kid. Если не проходит даже исходный токен, сначала восстановите стенд; подбирать секреты не нужно.
Валидный токен и чужой объект
Выпустите корректный токен для A. Убедитесь, что разрешённый запрос к объекту A работает, а тот же запрос к закрытому объекту B не возвращает данные B. Эти два результата проверяют решение о доступе уже после проверки токена.
| Проверка | Ожидание |
|---|---|
| Правильная подпись и claims | Принимать, затем проверить права |
| Чужой aud | Отклонить |
| Чужой iss | Отклонить |
| Истёк exp | Отклонить |
| Отсутствует exp | Отклонить при обязательном exp |
| Подменена подпись | Отклонить |
| Токен отсутствует | 401 |
| Верный JWT, чужой объект | Отказ по правам объекта |
Как учитывать ротацию и ошибки
Во время ротации определите доверенные ключи, сроки их действия и допустимое перекрытие. Неизвестный kid не должен включать обход проверки. Ошибка получения ключей тоже не является основанием доверять содержимому токена. Проверьте легитимный запрос с новым ключом и ожидаемое поведение старого. Не смешивайте ротацию обычного ключа и реагирование на компрометацию: у них могут быть разные сроки отзыва.
Первичные источники: RFC 8725: JWT Best Current Practices · OWASP: Session Management
Продолжить: IDOR и BOLA: как проверить доступ к чужим данным в своём API
Выход отзыв доступа и смена роли
Удалите тестового участника организации и проверьте старый access token, refresh и другие устройства. Заранее определите допустимое окно сохранения старых прав. Самодостаточный токен может оставаться криптографически корректным после выхода, если сервер не реализует отдельный отзыв. Обновление роли в интерфейсе не доказывает обновление серверных разрешений. Для чувствительных действий политика может требовать дополнительной проверки текущего членства.
Где хранить токен
Место хранения зависит от архитектуры. Доступный JavaScript токен связан с рисками XSS; автоматически отправляемая cookie требует анализа CSRF и параметров cookie. Нет одного универсального ответа для браузера, мобильного клиента и серверной интеграции. Используйте проверенные библиотеки и штатные механизмы сессий; это руководство не предлагает писать свою криптографию или передавать токен стороннему декодеру.
Первичные источники: RFC 8725: JWT Best Current Practices · OWASP: Session Management
Продолжить: Утечка .env .git или API-ключа: как закрыть доступ и проверить исправление
Почему корректный JWT не закрывает IDOR
После успешной проверки JWT запрос A к doc-b всё равно требует решения по объекту. Подпись не сообщает, принадлежит ли документ A и существует ли разрешённое приглашение. Проверки токена и IDOR должны иметь разные ожидания и доказательства. Если токен администратора используется вместо обычного тестового пользователя, межпользовательский сценарий может потерять смысл.
Как повторить проверку после исправления
После изменения проверяйте исходный отрицательный случай и контрольный положительный. Для Scantelio подготовьте поддерживаемый JWT-сценарий и ожидаемые claims там, где они нужны модулю. Неизвестные настройки нельзя объявлять проверенными. Зафиксируйте версию библиотеки и сборку; повторяйте сценарии при изменении issuer, ротации, refresh или модели членства.
Продолжить: Как добавить проверки безопасности в CI/CD и GitHub Actions
Воспроизводимые примеры и материалы
Учебные данные — синтетические. Файлы не содержат действующих ключей или клиентской базы. Запускайте примеры только в собственной изолированной тестовой среде.
- jwt-matrix.csv — редактируемый шаблон
- Выполняемый JWT-стенд: PyJWT, случайный локальный ключ, восемь проверок
Протокол проверки примера: версии, действия и наблюдения
Вопросы и ответы
Декодер показал role admin — это право?
Нет. Нужны доверенная проверка токена и отдельное решение сервера о разрешениях.
Можно узнать слабый секрет по виду JWT?
Форма токена не позволяет обоснованно сделать такой вывод. Здесь нет перебора ключей.
Достаточно проверить exp?
Нет. Применяется вся политика проверки: подпись, доверие к ключу, алгоритм и необходимые claims.
Выход всегда мгновенно отзывает JWT?
Нет. Это зависит от реализованных сессий, срока токена, refresh и механизма отзыва.
Где хранить токен безопаснее всего?
Решение зависит от архитектуры и рисков XSS/CSRF. Универсального безопасного места для всех клиентов нет.
Можно проверить без ожидаемых claims?
Часть наблюдений возможна, но неизвестная политика ограничивает вывод. Нельзя считать issuer или audience проверенными без соответствующих ожиданий.
Автор и источники
Редакция Scantelio: методика и границы проверки. Проверка примера: 2026-11-02.
Перенесите проверку на свой проект
Подготовить JWT-сценарииВыберите свой проект после входа. Ничего не сканируется без подтверждения и согласия.