Проверка безопасности API с тестовыми аккаунтами

Какие проблемы проверяются

Разделите четыре вопроса: доступна ли функция, разрешён ли объект, соблюдается ли граница организации и можно ли изменить защищённое поле. Скачивание счёта и экспорт заказов проверяются отдельными маршрутами. Диагностика JWT и ограничений запросов даёт вывод только в заданных условиях. SQLi и XSS относятся к поддерживаемым активным сценариям, а не к обещанию проверить любую форму и каждый браузерный путь.

Что подготовить владельцу

Подготовьте URL компонента, среду, OpenAPI либо известные операции, два аккаунта и синтетические записи. Для входа доступны поддерживаемые настройки Bearer, API key, cookies и JSON login; конкретный способ должен пройти диагностику. Сессия должна работать достаточно долго или иметь настроенное обновление. Не загружайте настоящий .env и не выдавайте универсальные production-права: тесту нужны ограниченные полномочия на известные данные.

Первичные источники: OWASP: REST Security

Продолжить: IDOR и BOLA: как проверить доступ к чужим данным в своём API

Как задать ожидаемые права

Матрица ниже отвечает на вопрос «кто может выполнить что над каким объектом». Публичный документ и приглашённый гость могут законно нарушать простое правило владельца. Запишите эти исключения заранее. Если ожидаемого ответа нет, одинаковые статусы A и B не доказывают ни безопасность, ни утечку. Для чтения используйте отдельный синтетический маркер, для записи — контроль состояния до и после.

Как работает авторизованный запуск

Сначала диагностируется вход. Затем проверяется собственный объект и только после этого чужой. В учебном API пользователь A читает свой заказ, но не заказ B и не отдельный маршрут его счёта. Истёкший токен или отсутствующий fixture делает проверку неполной: отказ без работающего положительного контроля нельзя засчитать исправлением. Обновление токена должно сохранять нужную тестовую личность, а не незаметно переключать её на администратора.

python3 access-fixture.py
# В другом терминале: до исправления — 200 с чужим объектом
curl -H "X-Fixture-User: a" "http://127.0.0.1:8769/documents/doc-b?mode=vulnerable"
# После — 403; doc-a остаётся доступен пользователю a
curl -H "X-Fixture-User: a" "http://127.0.0.1:8769/documents/doc-b?mode=fixed"

Первичные источники: OWASP: REST Security

Продолжить: Безопасность JWT: как проверить токены и отзыв доступа в своём API

Что можно и нельзя вывести из OpenAPI

Импорт OpenAPI 3 описывает доступные операции и параметры. Он не сообщает, какой документ принадлежит B и может ли гость его читать. Разрешите нужные операции чтения и добавьте тестовые данные отдельно. Внешние ссылки спецификации не являются разрешением загружать произвольные ресурсы; используйте поддерживаемый самодостаточный формат. Импорт Postman и общий анализ GraphQL этим руководством не обещаются.

Production и staging

Для production согласуйте ограниченный профиль отдельно. Проверки изменения полей и активных входов проводите на staging с подготовленными записями и планом очистки. Ответ 403 после PATCH не доказывает, что запись не успела измениться: приложение могло сохранить данные до ошибки. Сравните состояние через разрешённую контрольную операцию. Не используйте реальные заказы, платежи или клиентские документы как расходный материал теста.

Первичные источники: OWASP: REST Security

Продолжить: Как добавить проверки безопасности в CI/CD и GitHub Actions

Как читать покрытие и лимиты

Бюджет запросов и времени общий для запуска и его компонентов. Количество импортированных операций не равно количеству полностью исследованных сценариев. Уточняйте, что реально выполнено и почему остальное пропущено: истёкшая сессия, неподходящее окружение, ограничение цели или исчерпанный бюджет. Конкретные квоты берутся из каталога. Не повышайте скорость запросов, чтобы скрыть проблему покрытия за красивым числом проверок.

Как исправить и повторить

Для исправления сохраните минимальный запрос, нарушенное правило, версию сборки и маскированное доказательство. Повторите исходный сценарий после выкладки и проверьте, что владелец всё ещё работает с объектом. Затем закрепите проверку в расписании или CI. Автоматизация делает сценарий повторяемым, но не исследует все новые ветви бизнес-логики без обновления матрицы.

Продолжить: Проверка своего сайта на уязвимости по URL

Воспроизводимые примеры и материалы

Проверено: guides-1 · Python 3.13.0 · PyJWT 2.15.1

Учебные данные — синтетические. Файлы не содержат действующих ключей или клиентской базы. Запускайте примеры только в собственной изолированной тестовой среде.

• access-matrix.csv — редактируемый шаблон
• Локальный HTTP-стенд: уязвимый и исправленный режимы

Протокол проверки примера: версии, действия и наблюдения

Вопросы и ответы

Автор и источники

Редакция Scantelio: методика и границы проверки. Проверка примера: 2026-11-02.

• OWASP: REST Security
• OWASP: проверка авторизации