OWASP API Security Top 10 для QA — гайд с тест-кейсами

Большинство QA знают про SQL injection, XSS и веб-OWASP Top 10. При этом 90% уязвимостей в современных продуктах живут в API — а OWASP API Security Top 10 2023 — отдельный список, отличный от веб-Top 10, и в QA-курсах его обычно не разбирают.

Этот гайд — все десять угроз с тест-кейсами, готовыми curl-запросами и инструментами, которые есть в каждой QA-команде.

API1: Broken Object Level Authorization (BOLA)

Самая частая API-уязвимость. Endpoint типа GET /api/orders/{id} не проверяет, что заказ принадлежит залогиненному юзеру. Меняешь id в URL — получаешь чужой заказ.

strong

• Залогинься юзером A, открой свой заказ /api/orders/12345.
• Залогинься юзером B (не выходи из A), запроси /api/orders/12345 — должен быть 403 или 404.
• Перебери id (горизонтальный перебор) — заказы, профили, документы, чаты, лайки.
• Особое внимание: вложенные ресурсы. /api/orders/12345/items/67 — проверка авторизации часто только на orders, не на items.
• UUID не защищает — если есть list endpoint, можно вытащить чужие UUIDs.

strong

• Burp Suite Pro — Intruder для брута id, Autorize-плагин автоматизирует BOLA-проверки между сессиями.
• OWASP ZAP — Fuzzer + addons для access control testing.
• Postman/Bruno — runner с двумя environment'ами (юзер A, юзер B), параметризованные запросы.

API2: Broken Authentication

Всё, что ломает identity. Самые частые баги:

• JWT alg=none — клиент подсовывает токен с алгоритмом none, сервер принимает. Тест: декодировать токен, поменять header на {"alg":"none","typ":"JWT"}, убрать signature, отправить.
• JWT с weak secret — bruteforce через jwt_tool или hashcat. Если секрет вроде «secret123» или «changeme» — критично.
• Password reset token reuse — после использования токен должен инвалидироваться. Тест: попроси reset, используй ссылку, попробуй ещё раз с тем же токеном.
• Refresh token rotation — старый refresh должен инвалидироваться после выдачи нового. Тест: используй refresh1 → получи new tokens → попробуй ещё раз с refresh1.
• Account enumeration — login с существующим email возвращает «wrong password», с несуществующим «user not found». Должен быть одинаковый ответ.
• Rate limit на login — bruteforce защищён? Тест: 1000 попыток подряд от одного IP, потом от 1000 IP (distributed).

API3: Broken Object Property Level Authorization

Объединяет старые API3 (Excessive Data Exposure) и API6 (Mass Assignment) из 2019.

Excessive Data Exposure — endpoint возвращает поля, которые клиенту видеть не должен (password_hash, is_admin, internal_notes, deleted_at).

Mass Assignment — можно отправить лишние поля в PUT/PATCH, и сервер их применит. Классика: PATCH /api/users/me {"is_admin":true}.

strong

• Внимательно прочитай каждый response — что НЕ должно быть в ответе для этой роли?
• Сравни response для роли admin и user на одном endpoint — какие поля admin видит лишние?
• Для PUT/PATCH: попробуй послать ВСЕ поля из GET-ответа admin'а, включая is_admin, role, balance, status.
• Особо опасные поля: anything что начинается с is_, can_, has_, role, permission, balance, credit.

API4: Unrestricted Resource Consumption

API позволяет потребить непропорционально много ресурсов — память, CPU, deam-storage, сторонние API-вызовы (которые стоят денег).

strong

• Pagination без лимита: GET /api/users?limit=1000000 вместо limit<=100.
• File upload без лимита размера. Загрузи 5 ГБ файл — что произойдёт?
• Recursive structures: загрузи JSON со вложенностью 1000 уровней (parser-stack overflow).
• Zip bomb — 1 МБ zip разворачивается в 1 ГБ. Тест на endpoint, который unzips files.
• Webhook/notification flood: триггерь действие, которое шлёт N писем/notifications, проверь cap.
• GraphQL — depth и complexity limits настроены? Запрос вложенностью 10 уровней не должен валить сервер.
• SMS/email cost amplification: можешь отправить регистрационный SMS на 1000 номеров с одного IP за минуту?

API5: Broken Function Level Authorization

Похоже на BOLA, но не про objects, а про functions/endpoints. Обычный юзер находит admin-endpoint и может его вызвать.

strong

• Залогинься юзером, перебери методы на ресурсе: GET /api/users/123 ок, а DELETE? PUT?
• Поищи admin-endpoints в network-логах админ-панели, попробуй вызвать как обычный юзер: /api/admin/users, /api/internal/*.
• Прочитай swagger/openapi.json — там обычно перечислены ВСЕ endpoints. Если open для всех — голден mine.
• Старая версия API часто без новых auth-checks: /api/v1/admin/* работает, /api/v2/admin/* — 403.

API6: Unrestricted Access to Sensitive Business Flows

API позволяет автоматизировать flow, который должен быть «человеческим». Самый частый пример — scalping (бот скупает лимитированный товар за секунды), массовая регистрация (бот создаёт 10к аккаунтов с одного IP), наклад массовых отзывов.

strong

• Можешь ли ты автоматизировать flow «покупка лимитированного товара» через прямые API-вызовы (скрипт за 10 секунд)?
• Регистрация: 100 аккаунтов за минуту с одного IP. Сработала ли защита (CAPTCHA, rate limit, email verification)?
• Promo-code redemption: можешь ли применить промокод 1000 раз перебором аккаунтов?
• Friend invite spam: возможно ли отправить 10к invites?

API7: Server-Side Request Forgery (SSRF)

API принимает URL от пользователя и делает запрос на эту URL со своего сервера. Классическая атака — заставить сервер обратиться к internal endpoint.

strong

• Endpoints вроде «import from URL», «webhook tester», «preview link», «fetch favicon», «proxy».
• AWS metadata: http://169.254.169.254/latest/meta-data/ — если SSRF доступен, отсюда воруют instance credentials.
• Internal services: http://localhost:8080/admin, http://10.0.0.1/internal.
• Bypass через DNS rebinding, file:// scheme, gopher://.

strong

• Подсунь endpoint URL'ы вида http://localhost, http://127.0.0.1, http://169.254.169.254 — должны блокироваться.
• Bypass: 127.0.0.1.nip.io, 0.0.0.0, 2130706433 (десятичный 127.0.0.1), [::]:80.

API8: Security Misconfiguration

Кошёлка всего разного, что должно быть «по умолчанию закрыто», но открыто:

• CORS: Access-Control-Allow-Origin: * на API с credentials — критично.
• Debug headers: X-Debug-Token, X-Powered-By, Server с версиями фреймворка.
• Verbose errors: stack traces в production responses (показывают пути файлов, версии библиотек, SQL-запросы).
• Default credentials: admin/admin на admin-панели, root/root на DB, любые «password» в дефолтных конфигах.
• Insecure headers: отсутствие HSTS, CSP, X-Content-Type-Options.
• Open S3 buckets: проверь, что URL'ы внутри API ведут на приватные ресурсы.

strong

• OWASP ZAP — passive scan ловит большинство misconfig сразу.
• Mozilla Observatory (для веб-сайтов) — headers audit за 5 секунд.
• nmap + nuclei (nuclei -u https://api.example.com -t cves/) — ловит известные CVE и misconfigs.

API9: Improper Inventory Management

Старые версии API живут параллельно с новыми, undocumented endpoints, забытые dev/staging-эндпоинты доступны из прода.

strong

• Найди все версии API: /api/v1/*, /api/v2/*, /api/v3/* — какие живые? У старых обычно нет новых security-checks.
• Поищи документацию: /api/docs, /swagger, /openapi.json, /api/explorer — должны быть закрыты в проде.
• Поддомены: dev.example.com, staging.example.com, api-old.example.com — резолвятся? Доступны без auth?
• Внутренние endpoints: /health, /metrics, /actuator/*, /debug/* — открыты публично?

API10: Unsafe Consumption of APIs

Твой API доверяет ответам third-party API без валидации. Если third-party взломан или вернёт мусор — твой API передаст уязвимость дальше.

strong

• Через прокси (Burp/Proxyman) подмени ответ third-party API: что произойдёт, если вместо JSON прилетит HTML или binary?
• Подмени HTTP status: вернул 200 с error-body вместо 4xx — обработается корректно?
• Verify SSL: твой клиент проверяет cert third-party API? Подмени cert через MitM — поймёт?
• Redirect: third-party ответил 302 на attacker.com — клиент пойдёт следом? Должен быть allowlist для redirects.

Инструменты QA для API security

• Burp Suite Community (portswigger.net/burp) — бесплатно для большинства задач, Pro нужен для продвинутого fuzzing.
• OWASP ZAP (zaproxy.org) — полностью бесплатный, есть CI-mode для автоматизации в pipeline.
• RESTler (github.com/microsoft/restler-fuzzer) — fuzzer от Microsoft, генерит API-запросы из OpenAPI-спеки.
• Postman Security Audit — встроенный сканер security-issues в Postman Workspaces (платный).
• Newman + custom-scripts — для CI: запускаешь Postman-коллекции с pre-request скриптами под BOLA/auth-checks.
• nuclei — community-templates для известных API CVE, быстрый baseline.

Чек-лист QA перед релизом API

• BOLA: каждый endpoint c id-параметром тестировался от лица «чужого» юзера.
• JWT: проверены alg=none, weak secret, token expiration, refresh rotation.
• Response audit: нет полей вроде is_admin, password_hash, internal_notes в публичных ответах.
• Mass assignment: PUT/PATCH игнорирует поля, которые юзер не должен менять.
• Pagination имеет hard cap (например, max 100).
• File upload имеет size + MIME limit, тест на zip-bomb пройден.
• Admin endpoints возвращают 403 для не-admin юзеров.
• Rate limits настроены на login, register, password-reset, promo-redeem.
• Старые версии API не имеют новых auth-bypass (или удалены).
• Swagger/openapi.json/health/metrics закрыты в production.
• CORS, debug headers, verbose errors отключены в prod.
• SSRF: endpoints, принимающие URL, блокируют internal IPs (127.0.0.1, 169.254.169.254, 10.0.0.0/8).
• Third-party API responses валидируются (content-type, schema, status).
• В CI крутится nuclei или OWASP ZAP baseline scan.

API-security — это не «security-команда сделает». В большинстве случаев первый, кто видит broken auth или mass assignment — это QA на стейдже. Этот checklist встраивается в обычный API-регресс без bug-bounty-бюджета. Самое главное — научиться менять id в URL и читать response внимательно. Это половина BOLA и API3 ловится глазами и Postman'ом за день.