Замените одну цифру в API-запросе - и вы читаете чужую банковскую выписку. Без инструментов, без эксплойт-чейнов, без zero-day. Просто другое число в URL. По данным Snyk, именно так T-Mobile потеряла данные 37 миллионов клиентов - урегулирование обошлось в $350 миллионов. Peloton раскрыла тренировочную статистику любого пользователя через подмену user ID. Volkswagen MyVW в 2025 году отдавал геолокацию и телеметрию чужого автомобиля - достаточно было подставить другой VIN в API-запрос. BOLA IDOR уязвимость удерживает первую строчку OWASP API Security Top 10 с 2019 года, и я не вижу причин, почему это изменится. Это руководство - полная карта темы: от природы проблемы до конкретных техник обхода авторизации на уровне объектов.
| # | Тема | Подробнее |
|---|---|---|
| 1 | Полный разбор OWASP API Top 10 и методика тестирования | Практическая безопасность API |
| 2 | Поиск и репорт IDOR в bug bounty для максимальных выплат | IDOR в bug bounty |
| 3 | Горизонтальная и вертикальная эскалация с обходом UUID | IDOR эскалация привилегий |
| 4 | Паттерны авторизации, policy-as-code и чеклист для разработчика | Защита API от BOLA и IDOR |
| 5 | Bypass подписи Stripe webhook: техники и реальные CVE | Проверка подписи Stripe webhook |
| 6 | Broken Function Level Authorization в OpenClaw через /config и /debug handlers (CWE-863, API5:2023) | CVE-2026-32914 OpenClaw |
| 7 | Обход аутентификации REST API в Cisco Secure Workload (CWE-306, API2:2023) | CVE-2026-20223 Cisco |
| 8 | Cross-tenant IDOR в AI-платформе Langflow (активно эксплуатируется, CISA KEV 2026-07-07) | Langflow IDOR CVE-2026-55255 |
Что такое BOLA и IDOR: анатомия уязвимости #1 в OWASP API Security Top 10
Broken Object Level Authorization - класс уязвимостей авторизации, при которых API не проверяет, принадлежит ли запрашиваемый объект тому, кто его запрашивает. Пользователь аутентифицирован - у него валидный JWT-токен, сессионный cookie или API-ключ. Но между «кто вы» и «что вам разрешено видеть» зияет пропасть, в которую проваливаются данные миллионов пользователей.В каталоге MITRE классический BOLA/IDOR соотносится с CWE-639 - Authorization Bypass Through User-Controlled Key (дочерняя категория CWE-863 - Incorrect Authorization). Конкретные CVE могут классифицироваться шире: как CWE-863 (недостаточная авторизация) или CWE-306 (отсутствие аутентификации для критичной функции). Описание CWE-639 звучит прямо: «система авторизации не предотвращает доступ одного пользователя к данным другого при модификации ключа, идентифицирующего ресурс». Формулировка OWASP ещё конкретнее: API1:2023 - Broken Object Level Authorization, первая позиция в OWASP API Security Top 10 с момента создания рейтинга в 2019 году. В редакции 2023 года ничего не изменилось - всё та же первая строчка.
На практике BOLA уязвимость выглядит до обидного примитивно. Пользователь отправляет
GET /api/orders/10001 и видит свой заказ. Меняет 10001 на 10002 - видит чужой. Сервер вернул HTTP 200 с полным набором данных: ФИО, адрес, состав заказа, реквизиты оплаты. Запрос синтаксически корректен. Токен валиден. WAF молчит - нет ни инъекции, ни подозрительного payload. Просто другое число.Почему BOLA уязвимость API сидит на первом месте? Три свойства, которые редко встречаются вместе:
- Нулевой барьер входа. Не нужны инструменты - хватит браузера и прокси. По данным StackHawk, BOLA составляет около 40% всех атак на API.
- Невидимость для традиционных средств защиты. WAF, API-шлюзы, rate limiting видят аутентифицированного пользователя с корректным запросом. Ни одна сигнатура не сработает - потому что нечему срабатывать.
- Масштаб ущерба. Одна IDOR уязвимость открывает доступ ко всем записям в базе. Если ID предсказуем - скрипт выгребает всё за минуты.
Подробный разбор всех десяти рисков OWASP API Security: Практическая безопасность API: OWASP API Top 10, типовые уязвимости и методика тестирования
BOLA vs IDOR: 2 термина одной проблемы - когда какой использовать в репорте
Если вы работаете в application security хотя бы год, вы заметили: BOLA и IDOR описывают одно и то же. Путаница в терминологии - реальная проблема, которая влияет на восприятие пентест-отчётов и bug bounty репортов. Разберёмся.IDOR (Insecure Direct Object Reference) - термин из классического OWASP Top 10, впервые выделенный в 2007 году как категория A4. Фокус на механизме атаки: приложение использует прямую ссылку на внутренний объект (ключ БД, имя файла, последовательный ID), и атакующий манипулирует этой ссылкой. Термин знаком широкому кругу разработчиков и триажеров - его поймут все.
BOLA (Broken Object Level Authorization) - термин из OWASP API Security Top 10, появился в 2019 году. Та же фундаментальная проблема, но фокус смещён с вектора атаки на корневую причину. Не «ссылка небезопасна», а «авторизация сломана». По данным Snyk, BOLA учитывает, что уязвимости выходят за пределы URL-тампинга - они проявляются в телах запросов, заголовках, вложенных графах объектов и на границах микросервисов.
Все IDOR - это примеры BOLA, но не каждая BOLA связана с прямыми, легко манипулируемыми ссылками. Ядро проблемы одно: приложение доверяет пользовательскому идентификатору без серверной проверки авторизации.
Когда какой термин тащить в репорт:
- IDOR - при тестировании классических веб-приложений с монолитной архитектурой. Триажеры на большинстве bug bounty платформ распознают мгновенно.
- BOLA - при тестировании API-first приложений, микросервисов, SaaS. Ссылка на API1:2023 в репорте на HackerOne или Bugcrowd показывает, что вы понимаете контекст, и повышает шансы на приоритизацию.
- Оба термина - в отчётах для enterprise-клиентов, где читатели могут быть знакомы с любым из двух рейтингов: A01:2021 (Broken Access Control) из OWASP Top 10 для веб-приложений или API1:2023 из API Security Top 10.
4 типа API, где BOLA уязвимость эксплуатируется по-разному
BOLA - не только про REST. У каждого типа API свои паттерны, через которые ломается авторизация на уровне объектов. Большинство руководств останавливаются наGET /api/resource/{id}. В реальных проектах вы столкнётесь с GraphQL, gRPC и WebSocket - и каждый требует своего подхода.REST API
Классический и самый распространённый вектор. Атакующий подменяет идентификатор в URL (/api/orders/1001 → /api/orders/1002), в параметрах запроса, в теле POST/PUT или в HTTP-заголовках (X-User-Id, X-Account-Id). По данным Apyguard, REST API остаётся наиболее частой целью BOLA-атак. Проверяйте не только основные CRUD-эндпоинты - копайте вспомогательные: экспорт, отчёты, нотификации. Их часто забывают при внедрении авторизации.GraphQL
Единая точка входа (/graphql) скрывает десятки резолверов. BOLA в GraphQL часто прячется в nested-запросах: легитимный запрос к своему профилю через вложенные поля «проползает» к чужим объектам - user -> posts -> comments -> private_email. Подмена ID идёт через переменные: query { user(id: "victim_id") { email } }. Дополнительная опасность - introspection, которая раскрывает структуру API и все доступные поля. По сути, приложение само рисует вам карту атаки.gRPC
Используется для внутренних микросервисов. Бинарный формат Protobuf создаёт иллюзию security by obscurity - разработчики думают, что закрытый формат равен защите. По данным Apyguard, без серверных interceptors для проверки ownership gRPC-вызовы уязвимы точно так же, как REST. Формат сериализации - это не механизм безопасности.WebSocket
Persistent-соединения - ловушка для авторизации. Разработчики проверяют права при установке соединения, но забывают про re-авторизацию отдельных сообщений внутри сокета. Атакующий открывает легитимное соединение, потом отправляет subscribe-сообщение на чужой поток данных - приватный чат, тикет, поток транзакций. Сокеты - анархисты: один раз пустили, и дальше всё на доверии.При тестировании API на IDOR проверяйте все типы интерфейсов, не только REST-эндпоинты. GraphQL - смотрите nested resolvers. gRPC - декодируйте Protobuf и подменяйте ID в полях. WebSocket - перехватывайте и модифицируйте сообщения внутри установленного соединения.
Пример смежной проблемы - отсутствие аутентификации (CWE-306, ближе к API2:2023 - Broken Authentication, чем к BOLA): CVE-2026-20223 в Cisco Secure Workload: обход аутентификации REST API и методология тестирования
Классификация IDOR по импакту: чем отличается находка на $300 от находки на $5000
Не каждая IDOR уязвимость стоит одинаково. Триажеры bug bounty программ оценивают импакт, и от классификации зависит - получите вы P3 с минимальной выплатой или P1 с четырёхзначной суммой. Деление идёт по двум осям: тип операции и направление эскалации привилегий.По типу операции
| Тип | Описание | Типичный severity |
|---|---|---|
| Read | Чтение чужих данных: профили, документы, транзакции | P3-P2 |
| Write | Изменение чужих данных: смена email, настроек, пароля | P2-P1 |
| Delete | Удаление чужих объектов: файлы, проекты, аккаунты | P2-P1 |
| Create | Создание объектов от имени другого пользователя | P2 |
IDOR на чтение - самый частый тип и при этом самый недооценённый. Если утекают медицинские записи, финансовые данные или персональные документы - это P2 или P1, несмотря на отсутствие записи. Данные - это данные, и их утечка бьёт больнее, чем многие думают.
По направлению эскалации
- Горизонтальная (horizontal privilege escalation) - доступ к данным пользователя с тем же уровнем привилегий. Пользователь A читает данные пользователя B. Классический IDOR.
- Вертикальная - доступ к данным или функциям более привилегированного пользователя. Обычный юзер добирается до админской панели. Это уже ближе к Broken Function Level Authorization (API5:2023) и технике Valid Accounts (T1078).
Глубокий разбор с конкретными примерами обхода UUID-защиты: IDOR эскалация привилегий: горизонтальная и вертикальная эксплуатация с обходом UUID
Как найти IDOR уязвимость: пошаговая методология тестирования API
Поиск BOLA - не слепой перебор числовых ID в URL. Это системный процесс, который повторяется на каждой программе и каждом пентесте. Вот как я это делаю.Требования к окружению
- Burp Suite (Pro для полноценной работы; Community - для обучения). Версия 2024.x+ с поддержкой HTTP/2.
- Расширение Autorize (BApp Store) - автоматизирует проверку авторизации, отправляя каждый запрос параллельно с cookie/токеном другого пользователя. У Autorize есть известные проблемы совместимости с Burp Suite 2023+/2024+ (Montoya API) - если расширение глючит, берите Auth Analyzer или пишите скрипты на базе Turbo Intruder.
- Param Miner (BApp Store) - обнаружение скрытых параметров.
- Два тестовых аккаунта в целевом приложении - Attacker и Victim. У каждого должны быть свои объекты: документы, проекты, настройки.
- Текстовый файл для маппинга - записывайте каждый эндпоинт и найденные идентификаторы. Да, можно в блокноте. Главное - записывайте.
Шаг 1: маппинг эндпоинтов
Залогиньтесь под Victim и пройдите по всем функциям приложения с включённым Burp Proxy. Цель - собрать полную карту API. Фиксируйте каждый параметр, который выглядит как идентификатор объекта:- Числовые ID:
user_id=4521,document_id=89012 - UUID:
order=3f5c2e8a-29d7-4b05-a7d3-6e4f2a5b0001 - Slug:
project=my-secret-project - Составные ключи:
org_id=15&team_id=3&member_id=42
Шаг 2: настройка Autorize
Включите Autorize в Burp Suite. Укажите cookie или Authorization-заголовок аккаунта Attacker. Теперь каждый запрос под Victim автоматически дублируется с креденшиалами Attacker. Autorize подсвечивает ответы: зелёный - авторизация работает (403 или другие данные), красный - broken authorization (те же данные или 200 OK с чужим контентом).Шаг 3: систематическая подмена параметров
Переключитесь на аккаунт Attacker и подставляйте идентификаторы объектов Victim в каждый запрос через Burp Repeater. Ключевые сигналы обхода авторизации:- HTTP 200 с данными Victim - классический IDOR на чтение. Подтвердите, что в теле ответа именно чужие данные, а не ваши.
- HTTP 200 после PUT/PATCH с чужим ID - IDOR на запись. Проверьте, что данные Victim реально изменились (залогиньтесь под Victim и посмотрите).
- HTTP 200 вместо ожидаемого 403/404 - сервер вообще не проверяет авторизацию.
- Разный размер ответа - запрос с чужим ID возвращает body одного размера, а с несуществующим ID - другого. Данные утекают, даже если визуально ответ похож на ошибку.
/uploads/user_4521/passport.pdf - попробуйте user_4522. Серьёзно, попробуйте.Полная методология с примерами HTTP-запросов: IDOR уязвимость в bug bounty: как находить и репортить для максимальных выплат
7 техник эксплуатации BOLA, которые не ловят DAST-сканеры
DAST-инструменты заточены на инъекции и XSS. Уязвимости авторизации для них - слепая зона. По данным Snyk, BOLA - не технический дефект в привычном понимании, а логическая ошибка: запрос синтаксически корректный, ответ тоже, просто данные принадлежат не тому пользователю. Сканер с одним набором учётных данных физически не может это обнаружить - ему не с чем сравнивать.Ниже - техники, которые расширяют стандартный подход «подмени число в URL» и позволяют обойти даже частично реализованную авторизацию.
1. Parameter pollution. Дублирование параметра в запросе:
?user_id=attacker_id&user_id=victim_id. В зависимости от фреймворка обрабатывается первое значение, последнее или оба склеиваются. Если проверка авторизации берёт первый параметр, а бизнес-логика - последний, авторизация обходится. Работает чаще, чем хотелось бы.2. JSON globbing. Если API принимает JSON body, замените ID на массив
[1234, 1235], wildcard *, символ %, отрицательное значение -1 или десятичное 1235.0. Разные парсеры жуют эти значения по-разному, и часть из них обходит проверку.3. Переключение HTTP-метода. Эндпоинт
GET /api/users/{id} возвращает 403, а POST /api/users/{id} - 200 с данными. Два разных обработчика, один из которых забыли защитить. Проверяйте GET, POST, PUT, PATCH, DELETE для каждого endpoint. Скучно? Да. Но находки - регулярные.4. Подмена Content-Type. Тот же запрос с
Content-Type: application/json отклоняется, а с Content-Type: application/x-www-form-urlencoded или text/xml - проходит. Разные middleware обрабатывают тело запроса по-разному, и авторизация может быть привязана только к одному из них.5. Даунгрейд версии API. Если API доступен по
/api/v2/users/{id} и /api/v1/users/{id} - попробуйте старую версию. Новые содержат исправления, но старые часто остаются доступными. Это напрямую связано с OWASP API9:2023 - Improper Inventory Management. На одном проекте v1 висел без авторизации два года после «миграции» на v2.6. Замена статических ключевых слов. Разработчики используют
me, current, self для обозначения текущего пользователя. Замените на числовой ID: GET /api/users/me → GET /api/users/12345. Если API построен на разных обработчиках для me и числовых ID, второй маршрут может не иметь проверки.7. Second-order IDOR. Идентификатор сохраняется в одном месте, а используется в другом. Пример: функция экспорта данных по расписанию. При создании расписания user_id сохраняется в метаданных. При запуске - извлекается из метаданных без проверки авторизации. Подмена ID при создании приводит к экспорту чужих данных позже. Находить такие - отдельное удовольствие.
Когда техники НЕ работают: если авторизация реализована на уровне data access layer (ORM-запрос всегда содержит
WHERE owner_id = current_user), перечисленные техники обхода не помогут - проверка встроена в сам запрос к базе данных. Также если API-шлюз реализует object-level policy enforcement до маршрутизации к бэкенду.Смежные bypass-техники, применимые к webhook-авторизации: Проверка подписи Stripe webhook: bypass-техники и реальные CVE на пентесте
Cross-tenant IDOR в AI-платформе, демонстрирующий second-order паттерн (CVE-2026-55255 включена в CISA KEV с 2026-07-07 как активно эксплуатируемая - патч до 2026-07-10): Langflow IDOR CVE-2026-55255: пошаговая эксплуатация cross-tenant уязвимости в AI-платформе
Реальные взломы через broken object level authorization: от T-Mobile до Volkswagen
BOLA - не теоретическая угроза из учебника. За каждым инцидентом стоят конкретные HTTP-запросы, в которых не проверялся один параметр.T-Mobile (2023). По данным Snyk, утечка данных 37 миллионов клиентов привела к урегулированию class action на $350 миллионов. Точный технический механизм эксплуатации не был полностью раскрыт публично; Snyk характеризует инцидент как пример BOLA-паттерна - недостаточной авторизации при доступе к данным через API. $350M за отсутствие одной проверки - дорогая экономия на разработке.
Peloton. Подмена user ID в API-запросах позволяла получить персональные данные и статистику тренировок любого пользователя платформы. По данным Snyk - тот же паттерн: аутентификация есть, авторизации на уровне объекта нет.
Uber. По данным Traceable, исследователь Anand Prakash обнаружил эндпоинт, который принимал user ID и возвращал данные любого пользователя без проверки ownership. Один скрипт - и все пользователи Uber потенциально скомпрометированы.
Harbor (container registry). По данным Snyk, пользователь с ролью Maintenance мог переключить приватный проект на публичный и развернуть непроверенные образы, манипулируя метаданными проекта через неавторизованный API-вызов. BOLA, переходящая в вертикальную эскалацию - и вот уже проблема авторизации становится проблемой supply chain.
Volkswagen MyVW (2025). По данным Apyguard, манипуляция VIN-номером в API позволяла получить геолокацию, персональные данные владельца и телеметрию чужого автомобиля. API валидировал аутентификацию, но не проверял ownership VIN.
McDonald's / Paradox.ai (2025). По данным Apyguard, платформа для найма с чат-ботом использовала последовательные ID кандидатов. Инкрементация
/api/chat/10001 → /api/chat/10002 раскрывала имена, email-адреса, IP и результаты психологических тестов тысяч кандидатов. Последовательные ID в 2025 году - серьёзно?Общий паттерн у всех инцидентов: API проверял identity, но не ownership. Именно этот gap определяет CWE-639 и OWASP API1:2023.
Разбор CVE с эксплуатацией функциональной авторизации (CWE-863, ближе к API5:2023 - Broken Function Level Authorization): CVE-2026-32914: Broken Access Control в OpenClaw - эскалация привилегий через /config и /debug handlers
Защита от BOLA атак: почему RBAC недостаточно и когда нужен ABAC
Стандартный Role-Based Access Control (RBAC) отвечает на вопрос «могут ли менеджеры видеть инвойсы?». Но он не отвечает на вопрос посущественнее: «может ли ЭТОТ менеджер видеть ЭТОТ конкретный инвойс?». По данным Apyguard, именно это различие - между ролевой и объектной авторизацией - определяет, защищено приложение от BOLA или нет.| Критерий | RBAC | ABAC |
|---|---|---|
| Вопрос | «Разрешена ли эта операция этой роли?» | «Разрешена ли эта операция этому пользователю над этим объектом?» |
| Гранулярность | Роль → Функция | Пользователь → Объект |
| Защита от BOLA | Нет - роль «user» может видеть invoices, но чьи? | Да - проверяется ownership каждого объекта |
| Сложность | Низкая | Средняя-высокая |
Принципы защиты, которые работают
Проверка ownership на каждый запрос. Каждый API-эндпоинт, который обращается к пользовательскому ресурсу, должен содержать серверную проверку: принадлежит ли запрашиваемый объект текущему пользователю. Не на клиенте. Не на middleware. На уровне data access layer - там, где данные достаются из базы.Ограничение: проверка ownership на уровне ORM (например,
queryset.filter(owner=request.user) в Django) защищает от базового IDOR, но не от second-order IDOR, где ID сохраняется в промежуточном сервисе. Об этом часто забывают.UUID - не замена авторизации. Непредсказуемые идентификаторы затрудняют перебор, но UUID утекают через публичные профили, поисковые ответы API, email-рассылки и Wayback Machine. По данным StackHawk, obscurity - это defence-in-depth тактика, но не механизм безопасности. Красивый фантик, а не бронежилет.
Indirect references. Вместо реальных ID базы данных используйте session-specific токены, которые маппятся на серверные ID. Клиент видит
ref=abc123, сервер транслирует в internal_id=89012 с привязкой к текущей сессии. Даже если токен утечёт - он бесполезен в чужой сессии.Логирование и аномалии. Фиксируйте все cross-user запросы. Если пользователь A обращается к объектам пользователей B, C, D в течение минуты - это индикатор IDOR-эксплуатации. Sigma-правило
db_anomalous_query.yml из репозитория SigmaHQ может служить отправной точкой для детектирования таких паттернов.Полный чеклист защитных паттернов с примерами policy-as-code: Защита API от BOLA и IDOR: паттерны авторизации, policy-as-code и чеклист для разработчика
BOLA в 2026: AI-агенты, новая поверхность атаки и что делать прямо сейчас
Поверхность атаки расширяется в трёх направлениях одновременно. И ни одно из них не радует.По данным Snyk, AI-generated код ускоряет распространение BOLA: модели генерируют синтаксически корректный код, который выполняет бизнес-задачу, но систематически опускает проверку авторизации на уровне объектов. Разработчик копирует, тесты проходят - потому что тесты не покрывают cross-user сценарии. Copilot написал красивый CRUD - а ownership check? «Это потом добавим». Потом не добавляют.
По данным Apyguard, AI-агенты и LLM-powered копилоты создают новый вектор: внутренние API открываются для AI-систем, разработчики предполагают «внутреннее доверие», object-level checks пропускаются. Результат - AI-агенты извлекают тикеты, CRM-записи и HR-данные посторонних пользователей, потому что бэкенд проверял identity, но не ownership.
По данным IBM X-Force, рост атак с использованием действительных учётных данных составил 71% год к году в 2024 году. BOLA - идеальный вектор для этого тренда: атакующему не нужно красть чужие креды, достаточно своих собственных, чтобы получить чужие данные.
Что делать прямо сейчас:
- Проведите инвентаризацию API-эндпоинтов - особенно тех, что обращаются к пользовательским ресурсам. Если вы не знаете свою attack surface, вы не можете её защитить.
- Внедрите Autorize или аналог в CI/CD pipeline для автоматической проверки авторизации при каждом деплое.
- Убедитесь, что authorization check стоит на уровне data access layer, а не на уровне controller.
- Начните с аудита самых чувствительных эндпоинтов: финансовые данные, персональные документы, медицинские записи.
Большинство команд, которых я видел на проектах, решают проблему BOLA «одним слоем» - ставят UUID вместо числовых ID и считают себя защищёнными. UUID утекает через первый же эндпоинт, который возвращает список объектов или публичный профиль. И вот вы снова на старте - с единственной разницей, что теперь ваш ложный комфорт мешает инвестировать в настоящую проверку ownership.
Индустрия тратит непропорционально много ресурсов на сложные угрозы - zero-day, supply chain, AI-driven атаки - и непропорционально мало на базовую проверку «этот объект принадлежит этому пользователю?». Между тем, реальные инциденты на сотни миллионов долларов - T-Mobile, Uber, Volkswagen - это не zero-day. Это отсутствие одной строчки кода:
if object.owner_id != current_user.id: return 403.Прогноз: BOLA останется уязвимостью номер один, и разрыв с остальными рисками только вырастет. API-first архитектуры множатся, AI-агенты получают доступ к внутренним API без object-level проверок, а разработчики продолжают верить, что фреймворк решит задачу авторизации автоматически. Не решит. Ни один популярный фреймворк не реализует object-level authorization из коробки - это всегда ручная работа, привязанная к бизнес-логике конкретного приложения. Пока эта работа не станет обязательным этапом каждого code review, мы будем читать о новых утечках через подмену одного параметра.
