Insecure Direct Object Reference (IDOR) — уязвимость, при которой приложение использует пользовательский ввод для прямого обращения к объектам (записи в БД, файлы, ресурсы API), но не проверяет, имеет ли текущий пользователь право на доступ к запрашиваемому объекту. IDOR — один из самых распространённых подклассов Broken Access Control (A01:2021 в OWASP Top 10).

Как это работает. Вы авторизовались в личном кабинете и видите свой заказ по адресу /api/orders/1547. Меняете 1547 на 1548 — получаете чужой заказ с ФИО, адресом доставки и составом покупки. Сервер просто не проверил, ваш это заказ или нет.
Частое заблуждение — что замена инкрементальных ID на UUID закрывает проблему. Не закрывает. Если нет проверки авторизации на уровне объекта, атакующий всё равно может перехватить или подобрать идентификатор. IDOR — это всегда про отсутствие проверки прав, а не про формат ID.

Последствия:

• Массовая утечка ПДн: скрипт перебирает ID и выгружает тысячи записей за минуты
• Модификация чужих данных: смена email, пароля, адреса, привязанных карт у других пользователей
• Горизонтальная эскалация: доступ к ресурсам пользователей с тем же уровнем прав
• Вертикальная эскалация: доступ к административным объектам через подмену ID роли или tenant

Почему IDOR трудно обнаружить. Классические SAST/DAST-сканеры её практически не находят — уязвимость не в синтаксисе кода и не в известной сигнатуре, а в нарушении бизнес-логики. Сканер видит валидный HTTP 200 и считает, что всё штатно. Для обнаружения IDOR нужно отправить тот же запрос от имени другого пользователя и сравнить ответы — это задача тестирования бизнес-логики, а не сигнатурного анализа.

Защита:

• Проверка прав на уровне каждого объекта при каждом запросе. Не полагаться на то, что «пользователь не знает чужой ID»
• Серверная валидация принадлежности объекта текущей сессии. Где применимо — контекст сессии вместо передачи ID в параметрах: /api/my/orders вместо /api/orders/{id}
• Мониторинг аномалий доступа: массовый перебор ID, нетипичная частота запросов к разным объектам
• Регулярное тестирование авторизации с позиции разных ролей, включая автоматизированные проверки бизнес-логики

«IDOR — одна из самых недооценённых угроз в веб-приложениях. Стандартные сканеры её не ловят: запрос валидный, ответ 200, данные возвращаются — только чужие. Мы в Лаборатории кибербезопасности Servicepipe и Спикател делаем ставку на автоматизированное тестирование бизнес-логики. По сути, это единственный способ системно находить такие вещи до того, как их найдёт атакующий», — считает Михаил Хлебунов, руководитель лаборатории кибербезопасности Servicepipe и «Спикател».