Проверьте границы доступа в приложении

• Может ли пользователь получить объект другого пользователя или организации?
• Совпадают ли ограничения интерфейса с серверными проверками API?
• Даёт ли служебный токен больше полномочий, чем требуется его сценарию?
• Сохраняются ли ограничения при смене роли, завершении сессии или повторе действия?
• Можно ли связать несколько разрешённых по отдельности шагов в нежелательное действие?

Это вопросы для согласования области исследования, а не обещание полного покрытия любой системы.

Подготовьте тестовые аккаунты с различимыми ролями, отдельные тестовые объекты, ожидаемую матрицу доступа и описание входа. Спецификация OpenAPI помогает определить доступные операции, но её наличие не заменяет проверку работающего приложения.

SSO, многофакторный вход, CAPTCHA, короткоживущие токены и нестандартные клиентские протоколы обсуждаются заранее. Если войти или воспроизвести сценарий не удалось, это должно быть видно в ограничениях результата.

В отчёте важны исходная роль, затронутый объект, выполненное действие, наблюдаемый результат и границы разрешённой проверки. Один необычный HTTP-статус или предположение модели ещё не доказывает доступ к чужим данным.

Проверка изменения данных требует отдельного согласования и подходящих тестовых объектов. По возможности используйте тестовую среду; результаты в копии и на рабочей системе следует различать.

В кейсе ритейлера сервис принимал служебный токен устройства, но не проверял принадлежность исторического заказа. Проверка показала доступ к карточкам чужих заказов. Изменение и отмену проверяли с согласия заказчика на завершённых заказах; оплату не выполняли.

Доступ к текущим заказам новой системы не подтвердился. Этот вывод нельзя расширять до всех заказов или всех API ритейлера. Названия маршрутов и численные показатели в публикации изменены для анонимизации.

Начните с одного значимого сценария и заранее определите, чем будет подтверждён результат. Условия пилота и размещение помогают подготовить обсуждение.