API - это не просто технический интерфейс между фронтендом и бекендом. На сегодня API стал основным вектором атаки: приложения двигаются в сторону микросервисов, мобильных фронтов, третьих сторон и интеграций - и все это чаще всего через API. REST остался базой, но GraphQL и gRPC - это уже не будущее, это реальность многих production‑сред. Они дают гибкость и производительность, но открывают новые поверхности атаки, которые стандартные REST‑сканеры и классические подходы не покрывают.
Современные API - почему это не просто REST и чем опасны новые модели
REST vs GraphQL vs gRPC
REST - простая модель с множеством фиксированных URL и методов HTTP. Без хитростей: отправил GET/POST → получил ответ. Но это традиционная архитектура, к которой уже наворочена масса инструментов.GraphQL -единая точка входа API, где клиент описывает что и как запрашивать. Это сокращает трафик и увеличивает гибкость, но делает модель динамической, не ограниченной фиксированными путями и ответами. Если реализация не контролирует глубину и разрешения каждого поля, это сразу становится дверью для злоупотреблений.
gRPC -двойной уровень сложности: это RPC‑коммуникации по HTTP/2 с бинарной сериализацией через Protobuf. Преимущество - скорость, строго типизированные контракты, поддержка стриминга. Недостаток - традиционные веб‑сканеры практически не видят трафик, и тестирование требует специализированных инструментов.
У вас мог возникнуть вопрос: почему отдельный подход? Банально потому что гибкость запросов GraphQL, динамичные схемы, прозрачное отражение (reflection) gRPC, Protobuf и HTTP/2 создают attack surface (потенциальные точки входа), который не равнозначен REST‑API. Да, обычные уязвимости есть, но появляются новые векторы, о которых мы и сделали этот материал.
Если ты хочешь получить более широкий контекст об основных рисках API в 2026 г., включая тестирование и защиту, полезно взглянуть на материалы о базовых принципах безопасности API.
GraphQL pentest
GraphQL - это язык запросов и среда выполнения для API, который принимает запросы и возвращает результат по схеме. Это значит, что у тестера есть огромный простор для манипуляций, далеко выходящий за пределы стандартных REST‑методов.Reconnaissance - разведка поверхности атаки
Introspection: открытые двери в схему API
GraphQL изначально поддерживает introspection - запросы, которые возвращают полную схему API (типы, поля, аргументы). Это как если бы REST‑API по умолчанию отдавал OpenAPI/Swagger через один запрос. Если introspection включён в проде, ты получаешь карту всех нодов API.Это мощно, но опасно:
- позволяет построить полный граф API;
- выявить скрытые поля и мутации (даже без документации);
- помогает автоматизировать атаки (IDOR, BOLA, injection и др.).
Однако просто выключить introspection - не панацея: даже с выключенной introspection API может сдать схему через сообщения об ошибках, подсказки полей и трафик с фронтенда (если запросы видны в сети).
Разведка в GraphQL - это не перебор URL, это построение полной модели API перед тестами.
Чтобы лучше понять, как пентестеры подходят к тестированию API вообще, смотрите обзор навыков и подходов для перехода в пентест, в том числе особенностей работы с API‑запросами, ошибками авторизации и глубоким анализом входящих данных.
Типовые уязвимости GraphQL
Authorization flaws, IDOR и Broken Object Level Authorization
GraphQL не делает авторизацию по умолчанию на уровне полей - только на уровне resolvers. Типичная ошибка - контролировать доступ только на верхнем уровне запроса, а не на каждом поле или мутации. Тогда даже авторизованный пользователь может получить чужие данные, просто добавив параметры в запрос.Injection в GraphQL
GraphQL сам по себе не SQL, но данные, которые попадают в бекенд, могут течь дальше к базе данных или сервисам. Примеры возможных injection‑векторов:- SQL/NoSQL injection через аргументы поля;
- командная инъекция из resolver‑логики;
- SSRF/CRLF/HTTP request smuggling через некорректную обработку аргументов.
Information disclosure
Verbose ошибки, показ схемы в сообщениях об ошибке, отсутствие фильтрации ошибок - всё это даёт тестеру ускоренный доступ к структуре API и возможностям манипуляции. Это особенно плохо, когда schema содержит чувствительные типы.Advanced attacks: batching, nested queries и alias abuse
Batch attacks
GraphQL позволяет отправлять batch запросы - множество операций в одном HTTP. Это обычно выгодно с точки зрения эффективности, но такие запросы могут обходить rate limiting, если система считает только HTTP‑вызовы, а не логическое количество операций внутри HTTP.Тестер должен проверять, как система считает запросы:
- подсчитывает ли backend операции в батче отдельно;
- есть ли явные ограничения на максимальное количество операций в батче;
- как это влияет на лимиты по пользователю.
DoS через nested queries
GraphQL допускает произвольно глубокие вложения: один запрос может включать десятки или сотни уровней вглубь. Без ограничений по query depth это превращается в идеальный DoS‑вектор: сложный запрос потребляет CPU/память, и бекенд начинает тормозить или падать.Это не классический volumetric DoS, а логический - через нагрузку на парсинг и выполнение resolver’ов. Решение - вводить depth limiting и complexity analysis (стоимость запроса по сложности полей).
Alias‑based abuse
GraphQL позволяет использовать алиасы - псевдонимы для полей. Это может обмануть простейшие меры защиты или логирование: один и тот же endpoint с разными алиасами выглядит как уникальные поля, обходя некоторые фильтры.gRPC pentest: другая плоскость, другой стек атак
gRPC - это не HTTP/JSON. Это двоичный протокол поверх HTTP/2, с Protobuf на борту. Стандартные веб‑сканеры его не видят и приходится работать с протоколом напрямую.Reflection API abuse - когда сервис сдаёт свою контрактную модель
В gRPC существует server reflection, это схожий механизм с introspection в GraphQL: сервис может отдавать свой API‑контракт (методы, сообщения, типы) динамически. Это полезно инструментам вроде grpcurl и Postman для отладки, но в контексте безопасности это как если бы API отдавал свой protobuf‑описатель в ответ на запрос.Reflection можно отключить в проде, но если он включён, тестер сможет автоматически собрать список всех сервисов, методов и типов и начать взаимодействовать с ними.
Protobuf manipulation и типовая мутация данных
Protobuf структуры - это строго типизированные данные. Но при тестировании есть важные векторы:- отправка неожиданных значений для enum/required полей;
- плохая обработка неизвестных полей (unknown fields);
- манипуляции со streaming RPC;
- использование нестандартных пакетов данных для тестирования парсинга.
Authentication и Authorization bypass
gRPC использует прямые вызовы методов, и если авторизация слабая (например, только проверка токена на gateway, а не на каждом методе), тестер может вызвать методы напрямую с валидным токеном или злоупотребить отсутствием RBAC. Это типичная проблема, когда контролируется слой транспортировки, но не контрактная авторизация.
Инструменты в арсенале современного API‑пентестера
Здесь мы не просто перечисляем, а объясняем, когда и зачем брать тот или иной инструмент.Burp Suite и его расширения
- InQL живёт в Burp, помогает автоматизировать introspection GraphQL, визуализировать схему и строить атаки на её основе.
- GraphQL Raider - другой плагин для Burp, специализируется на enumeration и автоматизации атаки GraphQL.
Standalone и CLI‑инструменты
- Clairvoyance - углублённая spreadsheet‑ориентированная утилита для восстановления схемы GraphQL даже без introspection.
- GraphQL Voyager - визуализация схемы для понимания структуры API.
- grpcurl - незаменим для gRPC тестов: как curl для gRPC, позволяет исследовать Reflection, вызывать методы, описывать сервисы.
- Postman/Insomnia - удобны для построения и проверки запросов (GraphQL и gRPC), но скорее для прототипирования, чем автоматизированного поиска уязвимостей.
Современный API‑пентест - это целая дисциплина, которая выходит за рамки классического REST‑пентеста. GraphQL и gRPC требуют понимания схем, контрактов, динамики запросов, и атакующих техник, которые традиционные сканеры не найдут.
Последнее редактирование:
