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

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

API1: BOLA — Broken Object Level Authorization

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

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

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

API2: Broken Authentication

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

API3: BOPLA — Broken Object Property Level Authorization

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

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

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. Затем каждый метод проверяется на авторизацию (объект и функция), утечки данных и лимиты — вручную, на нескольких ролях.

# типичный набор для ручного API-теста
Burp Suite (Repeater, Intruder, Autorize)
mitmproxy / Postman   # разбор трафика и спецификаций
ffuf                  # перебор скрытых путей и версий
jwt_tool              # атаки на JWT (alg:none, слабый секрет)

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

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

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

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