securityapiowaspregression

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 — получаешь чужой заказ.

Как тестировать:

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

Инструменты:

  • 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}.

Тест-кейсы:

  • Внимательно прочитай каждый 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-вызовы (которые стоят денег).

Где обычно дыра:

  • 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 и может его вызвать.

Тест-кейсы:

  • Залогинься юзером, перебери методы на ресурсе: 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), накрутка массовых отзывов.

Тест-кейсы:

  • Можешь ли ты автоматизировать 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.

Где искать:

  • 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://.

Тест-кейс:

  • Подсунь 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 ведут на приватные ресурсы.

Инструменты:

  • 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-эндпоинты доступны из прода.

Тест-кейсы:

  • Найди все версии 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 передаст уязвимость дальше.

Тест-кейсы:

  • Через прокси (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’ом за день.