Когда берёшь в работу очередной API-пентест, первый вопрос должен быть - не «какой сканер запустить», а «как устроена логика этого сервиса». Сканер DAST найдёт отсутствие заголовков безопасности и открытый debug-эндпоинт. Но он не поймёт, что
GET /api/v1/orders/1337 отдаёт чужой заказ, если подменить ID. Сканер тут слеп как крот. Именно поэтому OWASP API Top 10 2023 - не абстрактный чеклист для менеджеров, а рабочая карта атакующего, по которой выстраивается методика тестирования безопасности API.Разбираю каждый пункт списка через конкретные векторы атак, HTTP-запросы и инструменты. Без теории ради теории - только то, что реально эксплуатируется на пентестах и в bug bounty.
Что изменилось в OWASP API Top 10 между 2019 и 2023
Прежде чем лезть в тестирование, стоит понять логику обновления. Список 2023 года - не косметическая правка. Три категории добавлены с нуля, две объединены, а фокус сместился с классических инъекций на уязвимости бизнес-логики.Ключевые изменения, которые влияют на методику API пентеста:
- API3:2019 (Excessive Data Exposure) + API6:2019 (Mass Assignment) слились в API3:2023 - Broken Object Property Level Authorization. Корневая причина одна: нет контроля на уровне свойств объекта. Для пентестера это значит, что тестирование mass assignment и утечки лишних полей - теперь один процесс.
- Injection (API8:2019) больше не выделена отдельно. Не потому что SQL-инъекции вымерли, а потому что в API-контексте авторизационные и логические баги статистически преобладают. Инъекции теперь живут внутри Security Misconfiguration (API8:2023, недостаточная валидация ввода) и Unsafe Consumption of APIs (API10:2023, доверие к данным из внешних источников).
- Три новых пункта: Unrestricted Access to Sensitive Business Flows (API6), Server Side Request Forgery (API7), Unsafe Consumption of APIs (API10). Все три требуют ручного анализа логики, а не сканирования.
Методика тестирования: от разведки к эксплуатации
Цепочка атаки на API повторяет классическую kill chain, но с нюансами, характерными для API-контекста:Разведка - сбор эндпоинтов, анализ документации (Swagger/OpenAPI), перехват трафика мобильного приложения через mitmproxy. На этом этапе работают Postman для импорта коллекций и
ffuf для обнаружения скрытых путей. Маппинг на MITRE ATT&CK: Active Scanning: Vulnerability Scanning (T1595.002, Reconnaissance).Тестирование аутентификации и авторизации - подмена токенов, перебор идентификаторов объектов, проверка разграничения ролей. Это ядро API-пентеста, и оно съедает 60-70% времени. У меня бывало - иногда и все 80%, если API сложный.
Эксплуатация - цепочка из нескольких слабостей. Например, Improper Inventory Management (забытый v1 API без авторизации) + BOLA = полный доступ к чужим данным. Маппинг: Data from Information Repositories (T1213, Collection) - доступ к данным через логические дефекты авторизации.
Закрепление и извлечение данных - использование полученного доступа для эксфильтрации или модификации. Маппинг: Data Manipulation (T1565, Impact).
Теперь - каждый пункт OWASP API Top 10 с позиции атакующего.
API1:2023 - BOLA уязвимость API (Broken Object Level Authorization)
BOLA сидит на первом месте не просто так - это самый распространённый и самый тривиальный в эксплуатации класс уязвимостей API. Суть: сервер доверяет идентификатору объекта в запросе клиента и не проверяет, принадлежит ли объект текущему пользователю. Замени один ID на другой - и получи чужие данные. Вот и весь «эксплойт».Как тестировать. Авторизуешься как пользователь A, находишь запрос вида
GET /api/v2/invoices/4521, копируешь его в Burp Repeater и меняешь 4521 на 4522. Если в ответе - чужой инвойс, это BOLA. Для автоматизации настраиваю Burp Intruder на перебор числовых ID или использую Autorize - расширение Burp, которое автоматически повторяет запросы с токеном другого пользователя и сравнивает ответы. Autorize - вообще must-have, без него BOLA-тестирование превращается в рутинный ад.Нюанс, который часто упускают: BOLA бывает не только в GET-запросах. Проверяйте
PUT /api/users/1338 (изменение чужого профиля), DELETE /api/comments/9921 (удаление чужого комментария). Каждый метод HTTP - отдельный вектор.Среди известных прецедентов - уязвимость USPS Informed Visibility API (2018, доступ к данным 60 млн пользователей через подмену идентификаторов) и баги в API Bumble (2020, доступ к произвольным профилям через перебор ID). BOLA регулярно приводит к раскрытию персональных данных миллионов пользователей.
ATT&CK маппинг: Прямого маппинга BOLA на MITRE ATT&CK нет - ATT&CK описывает тактики атакующего на уровне инфраструктуры, а не логические баги приложения. Ближайшая техника по результату: Data from Information Repositories (T1213, Collection). T1210 (Exploitation of Remote Services) не подходит - это про lateral movement между системами, а не про IDOR в веб-приложении.
API2:2023 - Broken Authentication
Сломанная аутентификация - это не только слабые пароли. В контексте REST API безопасности это JWT без проверки подписи, токены без срока действия, API-ключи как единственный механизм аутентификации (и да, такое до сих пор встречается в 2025-м).Что проверять на пентесте:
- Подмена алгоритма JWT: берёшь токен, декодируешь через
jwt_tool, меняешьalgс RS256 наnoneили HS256 (подписывая секретом из публичного ключа). Командаpython3 jwt_tool.py <token> -X aзапускает все известные атаки на алгоритм. - Отсутствие rate limiting на
/login- автоматизируешь перебор черезffuf -w passwords.txt -u https://target/api/auth -X POST -H 'Content-Type: application/json' -d '{"email":"victim@corp.com","password":"FUZZ"}' -fc 401,403и смотришь, прилетает ли 429 или блокировка. Тут есть подвох: многие API возвращают 200 OK с ошибкой в теле JSON, поэтому фильтрация-fc 401,403может не сработать. Используйте-mc all -mr '"token"'для матчинга успешных ответов или-fs <размер_ошибки>для фильтрации по размеру. - Утечка токенов: проверяешь, не передаются ли они в URL-параметрах (попадают в логи и Referer).
По данным ISACA, среди корневых причин - хранение паролей в открытом виде, отсутствие проверки подлинности токенов, смена пароля без верификации личности.
API3:2023 - Broken Object Property Level Authorization
Эта категория объединила две проблемы 2019 года: избыточную выдачу данных (Excessive Data Exposure) и mass assignment уязвимость. Корень один - нет контроля на уровне отдельных полей объекта.Excessive Data Exposure на практике. Отправляю
GET /api/users/me и изучаю ответ. Если вместе с именем и email прилетает password_hash, internal_id, role, ssn - это excessive data exposure. Фронтенд может не отображать эти поля, но они торчат в JSON-ответе, и любой Burp Suite их покажет. Разработчики часто думают: «Ну фронтенд же не показывает». Не всегда это правда.Mass assignment на практике. Регистрируюсь как обычный пользователь, затем повторяю запрос обновления профиля, добавляя в тело
"role": "admin" или "is_premium": true. Если сервер слепо принимает все поля из тела запроса без allowlist - это mass assignment. Нахожу такие поля через анализ OpenAPI-спецификации: если в схеме объекта User есть role, но в документации эндпоинта PUT /users оно не упомянуто - значит, стоит попробовать.Для обнаружения скрытых параметров использую Arjun:
arjun -u https://target/api/users/me -m JSON - он перебирает тысячи потенциальных имён параметров и находит те, на которые сервер реагирует изменением ответа.API4:2023 - Unrestricted Resource Consumption
Отсутствие ограничений на потребление ресурсов. В 2019 году это называлось «Lack of Resources & Rate Limiting», теперь название точнее - проблема в неограниченном потреблении.Что тестировать: отправить
GET /api/products?page_size=999999 и посмотреть, вернёт ли сервер все записи разом. Попробовать загрузить файл в 500 МБ через эндпоинт, ожидающий аватар. Запустить GraphQL-запрос с глубокой вложенностью - так называемая depth-атака. Удивительно, как часто сервер честно пытается всё это переварить.ATT&CK маппинг: Application Exhaustion Flood (T1499.003, Impact) - DoS через исчерпание ресурсов легитимными, но чрезмерными запросами.
По данным ISACA, типичные корневые причины: отсутствие таймаутов выполнения, отсутствие лимита на размер загружаемых файлов, неограниченное число записей в одном ответе.
API5:2023 - Broken Function Level Authorization (BFLA)
Если BOLA - горизонтальная эскалация (доступ к чужим объектам того же уровня), то BFLA - вертикальная (доступ к функциям другого уровня привилегий).Практический тест. Захватываю запрос обычного пользователя и меняю путь:
/api/users/profile → /api/admin/users. Или меняю метод: GET /api/orders/123 → DELETE /api/orders/123. Эндпоинты администраторов часто предсказуемы - /admin/, /management/, /internal/. Фаззинг директорий через ffuf -w api-endpoints.txt -u https://target/api/FUZZ -H "Authorization: Bearer <user_token>" выявляет скрытые функции, доступные с пользовательским токеном. На одном проекте мы так нашли /api/internal/export-all-users - висел без авторизации, просто никто не знал URL.API6:2023 - Unrestricted Access to Sensitive Business Flows
Новый пункт в списке 2023 года, и его нельзя найти сканером. Это не баг реализации - это отсутствие защиты бизнес-логики от автоматизированного злоупотребления.Примеры: массовая скупка лимитированных товаров ботами через API, автоматическая регистрация аккаунтов для спама, массовое использование купонов. По данным APIsec, атакующие пишут скрипты, распределённые по разным IP, которые скупают весь товар быстрее реальных покупателей.
Как тестировать. Определите критические бизнес-потоки (покупка, бронирование, отправка сообщений). Автоматизируйте их простым скриптом и проверьте: есть ли CAPTCHA, fingerprinting, лимиты на частоту операций. Если можно отправить 1000 заказов за минуту с одного токена - это уязвимость. Тут никакой Burp не поможет - нужно понимать бизнес-логику.
API7:2023 - Server Side Request Forgery (SSRF)
SSRF - новинка в API Top 10, но старая знакомая для пентестеров веб-приложений. API особенно подвержены SSRF, потому что часто принимают URL как параметр - для webhook-ов, импорта, preview.Тест: находишь параметр вроде
"callback_url": "https://example.com" или "image_url": "..." и подставляешь http://169.254.169.254/latest/meta-data/ (AWS metadata). Если в ответе - данные об инстансе, это критическая SSRF. Для out-of-band обнаружения использую Burp Collaborator или Interactsh.Как отмечают в блоге OWASP, REST API управления облаком, Kubernetes и Docker делают эксплуатацию SSRF особенно опасной - через неё можно добраться до секретов оркестратора. Одна SSRF в облаке - и ты уже читаешь IAM-креды.
API8:2023 - Security Misconfiguration
Широкая категория, покрывающая всё: от verbose-ошибок со стектрейсами до отсутствия CORS-политик и включённых HTTP-методов TRACE/OPTIONS.Чеклист для DAST API сканирования и ручной проверки:
- Отправить запрос с неправильным Content-Type - посмотреть, раскрывает ли ошибка внутренний стек (фреймворк, версию, путь на диске).
- Проверить CORS: отправить запрос с
Origin: https://evil.com- если ответ содержитAccess-Control-Allow-Origin: https://evil.com, это misconfiguration. - Проверить, включена ли Swagger UI на production:
/swagger-ui.html,/api-docs,/graphql(с интроспекцией). - Стандартные учётные данные на API-шлюзе.
nuclei -u https://target -t exposures/ -t misconfiguration/ автоматизирует значительную часть этих проверок. Я всегда начинаю с nuclei - он за пять минут находит то, что руками искал бы час.API9:2023 - Improper Inventory Management
Забытые эндпоинты, старые версии API без патчей, debug-пути на production - всё это Improper Inventory Management. Для пентестера это значит: всегда проверяй, существует ли/api/v1/ рядом с /api/v3/. Старая версия часто лишена авторизации, которую добавили позже. Классика жанра.Практика: перехватываю трафик мобильного приложения через mitmproxy, экспортирую все вызванные URL и сравниваю со Swagger-документацией. Расхождения - потенциальные shadow-эндпоинты. Дополнительно прогоняю
ffuf по словарям типа api-endpoints-v2.txt для обнаружения неописанных путей. Если в документации три эндпоинта, а в трафике - семь, значит четыре «потерянных» - ваши лучшие друзья.API10:2023 - Unsafe Consumption of APIs
Разработчики доверяют данным от сторонних API больше, чем пользовательскому вводу. Если приложение забирает данные из внешнего сервиса и вставляет их без валидации - атакующий может скомпрометировать внешний сервис и через него ударить по целевому приложению.Маппинг ATT&CK: Trusted Relationship (T1199, Initial Access) - атакующий компрометирует внешний сервис, с которым у целевого приложения установлены доверительные отношения, и через него доставляет вредоносные данные.
На пентесте проверяю: если приложение интегрируется с внешним API, что произойдёт при подмене ответа этого API (через mitmproxy)? Обрабатывается ли HTML/JS в данных? Есть ли таймауты и circuit breaker? Часто ответ - «нет, нет и нет».
Инструментарий для API пентеста
Стек, который использую на каждом проекте:| Задача | Инструмент | Применение |
|---|---|---|
| Перехват трафика | Burp Suite + Autorize | Все запросы через прокси, автоматическая проверка BOLA/BFLA |
| Мобильный трафик | mitmproxy | Перехват API-вызовов мобильных приложений |
| Фаззинг параметров | Arjun, ffuf | Обнаружение скрытых параметров и эндпоинтов |
| JWT-атаки | jwt_tool | Подмена алгоритмов, brute-force секрета |
| Автоматизация проверок | nuclei + кастомные темплейты | Массовые проверки misconfigurations и известных CVE |
| Реверс логики | Postman | Импорт OpenAPI, построение цепочек запросов |
| GraphQL | InQL (Burp extension) | Интроспекция, обнаружение мутаций, batch-атаки |
GraphQL security: отдельное направление тестирования
GraphQL-эндпоинты подвержены тем же категориям OWASP API Top 10, но со своими причудами. Интроспекция (запрос{__schema{types{name,fields{name}}}}) часто включена на production и раскрывает всю схему API - это одновременно API9 (Improper Inventory) и API8 (Misconfiguration). По сути, сервер сам рассказывает, как его ломать.Batch-запросы в GraphQL позволяют отправить сотни мутаций в одном HTTP-запросе, обходя rate limiting - прямой путь к API4 (Unrestricted Resource Consumption). Вложенные запросы с глубиной 15-20 уровней вызывают DoS на сервере.
Для тестирования GraphQL security использую InQL для Burp Suite: он парсит схему, генерирует все возможные запросы и мутации, позволяя быстро найти чувствительные операции.
Пошаговая методика: систематический API пентест
Когда получаешь scope на API-пентест, работай по структуре, а не хаотично тыкай в эндпоинты:Эта последовательность покрывает все десять пунктов OWASP API Top 10 и даёт структуру для отчёта.
Заключение
OWASP API Top 10 2023 - не теоретический список для презентаций. Это рабочая карта для тестирования безопасности API, где каждая категория транслируется в конкретные проверки. Главный тренд - смещение от инъекций к логическим уязвимостям: BOLA, BFLA, business logic abuse. Эти баги не найдёт ни один DAST-сканер - они требуют понимания контекста приложения и ручного тестирования.Если строите методику API пентеста - начните с авторизации. API1, API3, API5 - три пункта из десяти, и все про контроль доступа. Затем аутентификация и логика. Автоматизируйте рутину через Autorize, nuclei и ffuf, но не полагайтесь только на инструменты.
Самые критичные баги в API находятся руками - в Burp Repeater, при замене одного ID на другой. Попробуйте прямо сейчас: возьмите любой API, с которым работаете, и подмените ID в паре запросов. Результат может неприятно удивить.
Последнее редактирование модератором:
