Тестирование безопасности API для REST и GraphQL
Для команд, выпускающих API REST и GraphQL, это преимущественно ручной пентест, сфокусированный на уязвимостях, которые пропускают автоматические сканеры: авторизация на уровне объекта и функции, злоупотребление бизнес-логикой и обработка токенов. Мы тестируем так, как это делает реальный атакующий с валидным токеном с низкими правами — перебираем объекты, подделываем личности и связываем потоки — а затем передаём воспроизводимые доказательства и исправления, сопоставленные с OWASP API Security Top 10 (2023).
Что мы проверяем
Сломанная авторизация на уровне объекта (BOLA/IDOR — API1:2023)
Подменяем идентификаторы объектов, UUID и вложенные ссылки на ресурсы между двумя аккаунтами, доказывая, что один арендатор может читать или изменять данные другого.
Сломанная аутентификация (API2:2023)
Атакуем вход, выдачу и обновление токенов: устойчивость к credential stuffing, слабые JWT (alg:none, путаница HS256/RS256, непроверенные подписи), отсутствие истечения/отзыва токенов и обход OTP/сброса пароля.
Сломанная авторизация на уровне свойств / Mass Assignment (API3:2023)
Внедряем неожиданные поля (role, isAdmin, balance, tenant_id) в запросы записи и проверяем избыточное раскрытие свойств, которые клиент не должен получать.
Неограниченное потребление ресурсов (API4:2023)
Проверяем отсутствие или обход лимитов запросов, неограниченную пагинацию/размер страницы и дорогие запросы, дающие DoS уровня приложения и усиление затрат.
Сломанная авторизация на уровне функций (API5:2023)
Вызываем административные и привилегированные эндпоинты, запрещённые HTTP-методы и скрытые функции токеном обычного пользователя, чтобы выявить вертикальную эскалацию привилегий.
Неограниченный доступ к чувствительным бизнес-потокам (API6:2023)
Злоупотребляем потоками — оформление заказа, рефералы, купоны, регистрация, бронирование — на предмет автоматизации и логики: race conditions и манипуляции отрицательным количеством.
Server-Side Request Forgery (API7:2023)
Тестируем параметры URL/webhook/импорта на SSRF к метаданным облака (169.254.169.254), внутренним сервисам и DNS-rebinding, включая слепые/out-of-band варианты.
Специфичные для GraphQL злоупотребления
Открытая интроспекция, атаки глубокой вложенностью запросов, батчинг алиасов/полей для обхода лимитов и инъекции через аргументы резолверов.
Методология
- 1
Определение объёма и авторизация
Письменно согласуем цели, среды, тестовые аккаунты (минимум две роли/арендатора) и правила проведения, а также подтверждаем, что вы владеете или уполномочены тестировать API, до отправки любого трафика.
- 2
Инвентаризация и разведка API (API9)
По WSTG перечисляем эндпоинты из OpenAPI/Swagger, интроспекции GraphQL, трафика мобильных/SPA и перехвата трафика, сопоставляя версии, shadow- и устаревшие эндпоинты.
- 3
Анализ аутентификации и сессий
Исследуем потоки OAuth2/OIDC, структуру и подпись JWT, время жизни токена, обновление и выход, следуя проверкам WSTG-ATHN/WSTG-SESS.
- 4
Тестирование авторизации и бизнес-логики
Ключевая ручная фаза: матрицы BOLA/BFLA по ролям и арендаторам (WSTG-ATHZ), mass assignment и злоупотребление чувствительными потоками на двух живых аккаунтах.
- 5
Инъекции, мисконфигурация и потребление
Тестируем инъекции (SQL/NoSQL/command), ошибки конфигурации (CORS, подробные ошибки, заголовки), лимиты запросов и небезопасное потребление сторонних API.
- 6
Отчёт, ретест и разбор
Каждая находка снабжается доказательством запрос/ответ, оценкой CVSS и рекомендациями; бесплатный ретест проверяет исправления, затем следует разбор с инженером.
Стандарты и ссылки
Что вы получаете
- Технический отчёт — Описание каждой находки с шагами воспроизведения, сырым запросом/ответом, оценкой CVSS и сопоставлением с OWASP API/WSTG.
- Резюме для руководства — Одностраничное изложение рисков для менеджмента и аудиторов с общей оценкой состояния и приоритизированной дорожной картой устранения.
- Рекомендации по устранению — Конкретные исправления с учётом фреймворка для каждой проблемы — проверки авторизации, ограничения схемы, усиление токенов — без общих фраз.
- Бесплатный ретест и аттестация — Повторно проверяем устранённые находки и выдаём письмо-аттестацию, пригодное для клиентов, партнёров и доказательств соответствия.
Частые вопросы
Что нужно предоставить до начала теста?+
Среду staging или близкую к продакшену, документацию API (OpenAPI/Swagger или схему GraphQL, если есть) и минимум два тестовых аккаунта на роль/арендатора, чтобы мы могли доказать дефекты авторизации. Для аутентифицированных тестов нужны рабочие учётные данные или токены, а разрешение IP по спискам следует подготовить заранее.
Сколько длится пентест API?+
Типичное API REST или GraphQL на 30–80 эндпоинтов занимает 5–10 рабочих дней вместе с отчётом. Основные факторы — число эндпоинтов, количество ролей/арендаторов и сложность бизнес-потоков. Фиксированные сроки и цену вы получаете после короткого созвона по объёму.
Не сломает ли тест продакшен и не утекут ли данные?+
По умолчанию мы тестируем недеструктивно и согласуем потенциально нарушающие проверки (rate-limit, класс DoS) в сервисном окне. Предпочтителен staging; если тестируем продакшен, используем помеченные тестовые данные и не изменяем реальные записи клиентов.
Входит ли бесплатный ретест?+
Да. После того как ваша команда исправит находки, мы повторно проверяем их без доплаты в согласованном окне и обновляем статус в отчёте, давая доказательство, что проблемы действительно закрыты.
Это легально и как оформляется авторизация?+
Тестирование проводится только по подписанному согласию и соглашению об объёме, подтверждающему, что вы владеете или контролируете цель. Это делает работу законной, точно определяет активы в объёме и защищает обе стороны. Всё время мы придерживаемся строгого документа правил проведения.