Безопасность API: разбор OWASP API Security Top 10

API: ядро современных веб-, мобильных и IoT-приложений, и одновременно их главная поверхность атаки. Gartner ещё несколько лет назад назвал API самым частым вектором атак на веб-приложения, и статистика утечек это подтверждает: почти все громкие «взломы через API» последних лет — это баги авторизации, а не хитрые эксплойты. У API свои риски, собранные в OWASP API Security Top 10 (2023). Разбираем по пунктам. Проверяем на пентесте API и микросервисов.

Реальные утечки через API

• Optus (2022): неаутентифицированный API с перебираемыми id: ~9,8 млн клиентов.
• T-Mobile (2023): через один API утекли данные 37 млн аккаунтов (BOLA/broken auth).
• Peloton, USPS, Venmo — API отдавали данные любого пользователя по id или публично. Это всё BOLA — риск №1 списка.

API1: BOLA — Broken Object Level Authorization

Причина большинства крупных утечек. По сути это IDOR на уровне API: доступ к чужому объекту по id.

GET /api/v2/users/1337/messages    → 200 (свои сообщения)
GET /api/v2/users/1338/messages    → 200 (ЧУЖИЕ сообщения!)  ← BOLA

Защита: проверять владельца объекта на сервере при каждом запросе; id пользователя брать из токена, не из URL.

API2: Broken Authentication

Слабая аутентификация открывает чужие аккаунты: нет лимита попыток (брутфорс), бессрочные токены, предсказуемые токены сброса. Отдельная классика, alg: none в JWT: приложение принимает токен без подписи.

# JWT-атака alg:none — сервер принимает неподписанный токен
{"alg":"none","typ":"JWT"}.{"sub":"admin","role":"admin"}.
# инструмент: jwt_tool -X n  (проверка alg:none, слабого секрета, kid-инъекций)

API3: BOPLA — авторизация на уровне свойств

Excessive Data Exposure: API отдаёт больше полей, чем показывает UI (password_hash, is_admin, внутренние заметки, «UI их не рисует, значит норм»). Mass Assignment: API принимает лишние поля:

PATCH /api/users/me
{ "nickname": "bob", "role": "admin" }    # если role не в allow-list → самоповышение до админа

Остальные риски списка (2023)

• API4: Unrestricted Resource Consumption — нет лимитов → DoS и «денежные» атаки; критично для GraphQL.
• API5: BFLA — доступ к админ-функциям обычным пользователем (сменил метод/путь → попал в админку).
• API6: неограниченный доступ к чувствительным бизнес-потокам (массовая скупка, накрутка).
• API7: SSRF — сервер ходит по URL из запроса (см. разбор SSRF).
• API8: небезопасная конфигурация, CORS-ошибки, verbose-ошибки.
• API9: плохой инвентарь — забытые /api/v1, теневые и debug-эндпоинты.
• API10: небезопасное потребление сторонних API.

Как мы тестируем API

Первый шаг: полная карта эндпоинтов: спецификация OpenAPI/Swagger, перехват трафика мобильного приложения в Burp, декомпиляция APK. Затем каждый метод проверяется на авторизацию (объект и функция), утечки данных и лимиты, вручную, на нескольких ролях и аккаунтах.

# типовой набор для ручного API-теста
Burp Suite (Repeater, Intruder, Autorize)  # авторизация, BOLA/BFLA
mitmproxy / Postman                        # разбор трафика и спецификаций
ffuf -w wordlist -u https://api.site/FUZZ  # скрытые пути, старые версии
jwt_tool                                   # атаки на JWT

Экспертное наблюдение: самая частая критичная связка, это BOLA + BFLA. Пользователь меняет и id объекта, и «уровень» ручки, добираясь до чужих данных через административный эндпоинт, о котором «никто не должен был знать». Скрытность эндпоинта — это не безопасность: мы находим такие ручки перебором за минуты.

Чек-лист безопасности API

1. Авторизация на уровне объекта и функции, на сервере, для каждого запроса.
2. Отдавать и принимать только явно разрешённые поля (allow-list, DTO).
3. Строгая аутентификация, короткоживущие токены, проверка подписи и alg у JWT.
4. Лимиты, квоты и пагинация против злоупотреблений и DoS.
5. Актуальный инвентарь: закрыть старые версии, debug- и теневые эндпоинты.

Читайте также: IDOR на практике, SSRF, Безопасность GraphQL.

Профильные услуги SecurityLab: тестирование на проникновение · пентест веб-приложений · Пентест мобильных приложений.