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

Что такое IDOR и BOLA

Пользователь может иметь право открыть раздел документов и при этом не иметь права читать конкретный документ. BOLA касается выбранного объекта, тогда как вызов административной функции обычным пользователем — другая граница доступа. Иногда один маршрут нарушает обе границы. В отчёте фиксируйте конкретное нарушенное правило и доказательство, а не только название класса уязвимости.

Как подготовить два независимых контекста

Создайте A и B в разных тестовых организациях, doc-a и doc-b с различимыми приватными маркерами. Убедитесь, что нет разрешённого общего доступа. Отдельно создайте приглашённого гостя для проверки законного исключения. Сохраните ID и ожидаемые права в fixture. Если B не может прочитать doc-b, исходные данные или сессия неисправны и дальнейший отказ A ничего не доказывает.

Первичные источники: OWASP: BOLA · OWASP: Authorization

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

Пошаговая проверка чтения

Выполните три чтения: A запрашивает doc-a, B запрашивает doc-b, A запрашивает doc-b. В последнем ответе не должно быть маркера B. Статус 200 с общей страницей входа не равен утечке; статус 404 без подтверждения существования объекта не равен исправлению. Учебные запросы используют только синтетические личности и локальный сервис. Фиксируйте содержимое минимально, без копирования полноценного документа.

Где ещё проверять тот же объект

Проверьте известные дополнительные пути: /documents/doc-b/download, превью и экспорт. Основной маршрут может иметь проверку владельца, а загрузчик файла — обращаться к хранилищу напрямую. Для фоновой задачи отдельно проверьте получение результата по её ID. Подписанные общие ссылки требуют собственной политики срока и получателя; не объявляйте разрешённый гостевой доступ ошибкой только потому, что пользователь не владелец.

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: BOLA · OWASP: Authorization

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

Проверка изменения и защищённых полей

На staging сохраните исходные owner_id, tenant_id и роль. Попробуйте только заранее разрешённое изменение тестовой записи, затем прочитайте состояние через доверенный контроль. Если сервер ответил ошибкой, но владелец поменялся, запрет не сработал. Верните fixture в исходное состояние. Возможность принять неизвестное поле в JSON без эффекта не является доказательством повышения полномочий.

Как исправлять на сервере

Загрузите личность из проверенной сессии, объект — из доверенного хранилища, членство — из серверной модели. Решение должно учитывать владельца, tenant, роль и разрешённые приглашения. organizationId из тела запроса не является доказательством членства. Пример ниже помечен как псевдокод: замените canRead на реальную политику приложения и проверяйте её при каждом пути доступа.

Первичные источники: OWASP: BOLA · OWASP: Authorization

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

Как доказать исправление

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

Как автоматизировать повторение

Сохраните матрицу, fixture, версию правила и минимальное доказательство. После изменений данных обновляйте известные ID, а после смены входа — тестовые сессии. В Scantelio настройте поддерживаемый сценарий доступа и затем ретест находки. Неизвестный объект, публичный sessionPath или недоступная личность должны приводить к ограниченному выводу, а не к отметке «изоляция проверена».

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

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

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

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

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

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

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

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

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

• OWASP: BOLA
• OWASP: Authorization