РУКОВОДСТВО 04 · ВЕБ-ПРИЛОЖЕНИЯ И API
IDOR и BOLA: модель доступа к объектам API
IDOR — ошибка проверки права на выбранный объект; в API такой риск часто называют BOLA. На своём стенде проверьте A→A, B→B и A→B: законные чтения должны работать, приватный документ B не должен открываться A. UUID и скрытая ссылка не заменяют серверную проверку. Используйте известные тестовые объекты, а не перебор чужих адресов.
Повторить на своём стенде Посмотреть результат без регистрацииЧто изменилось после исправления IDOR?
На локальном HTTP-стенде A мог прочитать приватный документ B. После исправления тот же запрос вернул 403, а оба владельца сохранили доступ к своим документам.
- A читает документ B
- HTTP 200 → HTTP 403
- A читает свой документ, B читает свой
- HTTP 200 → HTTP 200
Понадобятся вход, подтверждение владения и согласие. Для авторизованных сценариев, мониторинга и CI нужен Pro или Business.
Содержание
Как проверить доступ к чужим данным в API по OpenAPI
Запрос от владельца документа
Найдите в OpenAPI операцию чтения одного объекта. Подставьте ID существующего приватного документа B и отправьте запрос с токеном B. Убедитесь, что тело ответа содержит уникальный маркер документа.
Тот же запрос от другого пользователя
Повторите запрос с токеном A, сохранив путь и параметры. Если A получил тот же приватный маркер вопреки политике доступа, зафиксируйте нарушение. Отдельно проверьте скачивание и экспорт, если у объекта есть такие маршруты.
Первичные источники: OWASP: BOLA
Краткий ответ и условия проверки
BOLA — ошибка доступа к объекту: пользователь A получает объект B. Предсказуемый идентификатор сам по себе не доказывает уязвимость.
Два пользователя разных организаций и приватные тестовые объекты с известными владельцами.
| Проверка | Ожидаемое доказательство |
|---|---|
| Действие | Не меняйте ID объекта, меняйте только аккаунт; владелец должен читать объект, другая организация — нет. |
| Положительный и отрицательный контроль | Уязвимый пример даёт доказательство, исправленный — нет. Успешный контрольный запрос подтверждает доступность цели. |
| Блокировка или недостающие данные | Отметьте проверку как пропущенную или незавершённую с причиной. Отсутствие аккаунта, ответ WAF и таймаут не означают отсутствие проблем. |
| После исправления | Повторите проверку той же цели, аккаунта и объекта. Сохраните исходное доказательство и новый результат; покрытие ограничено выполненными сценариями. |
Продолжить: Посмотреть пример отчёта
Продолжить: Покрытие и необходимые данные
Что такое 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 без подтверждения существования объекта не равен исправлению. Учебные запросы используют только синтетические личности и локальный сервис. Фиксируйте содержимое минимально, без копирования полноценного документа.
| Контекст | Объект | Метод | Ожидание |
|---|---|---|---|
| A | doc-a | GET | 200 |
| A | doc-b | GET | 403 |
| B | doc-b | GET | 200 |
| B | doc-a | GET | 403 |
| guest | doc-a | GET | 200 |
| guest | doc-b | GET | 403 |
| anonymous | doc-a | GET | 401 |
| A | doc-b/download | GET | 403 |
| B | doc-a/download | GET | 403 |
| A | doc-a/download | GET | 200 |
| B | doc-b/download | GET | 200 |
| anonymous | doc-b/download | GET | 401 |
Где ещё проверять тот же объект
Проверьте известные дополнительные пути: /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
Воспроизводимые примеры и материалы
Учебные данные — синтетические. Файлы не содержат действующих ключей или клиентской базы. Запускайте примеры только в собственной изолированной тестовой среде.
Протокол проверки примера: версии, действия и наблюдения
Вопросы и ответы
UUID защищает от IDOR?
Нет. Непредсказуемый идентификатор не заменяет проверку разрешения на объект.
Отказ 404 означает исправление?
Только если объект существует, контроль владельца работает и отказ соответствует политике. Сам по себе статус недостаточен.
Почему два пользователя одной команды видят документ?
Это может быть разрешённый общий доступ. Ожидание зависит от вашей модели членства и приглашений.
IDOR бывает только в GET?
Нет, ошибка может затрагивать изменение, удаление и другие действия. Тесты записи требуют подготовленной среды.
Можно найти все IDOR автоматически?
Без полной модели прав, известных объектов и покрытия такой гарантии нет.
BOLA и доступ к админке — одно и то же?
Нет. BOLA касается права на объект; доступ к административной функции относится к функциональной авторизации.
Автор и источники
Редакция Scantelio: методика и границы проверки. Проверка примера: 2026-11-02.
Перенесите проверку на свой проект
Повторить на своём стендеВыберите свой проект после входа. Ничего не сканируется без подтверждения и согласия.