GraphQL массово заменяет REST API, но его безопасность — слабое звено. Компании внедряют быстро, защищают медленно.
🔍 Почему GraphQL опаснее REST:
— один endpoint вместо множества → сложнее мониторить
— клиент сам формирует запрос → больше контроля атакующему
— introspection по умолчанию включен → полная карта API бесплатно
➡️ Как атакуют:
1. Introspection Mining
Запрос
__schema выдает всю структуру API: типы, поля, аргументы. Даже если endpoint не документирован — получишь full disclosure.
{__schema{types{name,fields{name}}}}
2. Batching Attack
Один HTTP-запрос = 1000 GraphQL-операций. Rate limit обходится тривиально, можно брутить токены/пароли массово.
3. Alias Overloading
Запросить одно и то же поле 10000 раз под разными именами → DoS через CPU exhaustion.
{
user1: user(id:1){name}
user2: user(id:1){name}
...
user9999: user(id:1){name}
}
4. Nested Query Bomb
Циклические зависимости в схеме (user→posts→author→posts...) → экспоненциальный рост запросов к БД.
5. Field Suggestions Leak
Опечатка в названии поля? GraphQL сам подскажет правильное — включая приватные поля, которые думали скрыть.
😵 Типичный сценарий атаки:
Пентестеры регулярно находят открытые GraphQL endpoints у SaaS-сервисов. Через introspection обнаруживают internal-запросы типа
adminQuery или internalUserData, которые не были в публичной документации. Результат: массовая утечка данных клиентов.🛡 Что делать defenders:
—
отключить introspection в production
(если не нужен публично)
— лимиты на
query depth
(макс. 5-7 уровней) и
complexity
—
persisted queries
вместо arbitrary запросов
— мониторинг аномальных паттернов (>100 алиасов, батчинг >10 запросов)
—
field-level authorization
, а не только endpoint-level
📎 Источники:
→ OWASP GraphQL Cheat Sheet
→ GraphQL Batching Attack
→ Exploiting GraphQL
🐸 Библиотека хакера
#breach_breakdown #graphql