Защита сложности запросов: depth, cost, persisted queries

Depth limiting

Почему глубина так важна, если DataLoader уже занимается батчингом? Потому что при большой глубине число листьев растёт экспоненциально — DataLoader не в состоянии отбатчить 10^22 ID. Depth-limiter обходит AST (дерево абстрактного синтаксиса) запроса и отклоняет документы, чей уровень вложенности превышает настроенный максимум. Типичный production-лимит: 7–10 уровней. Проверка работает на фазе validation — до запуска любого резолвера, до обращения к любой базе.

{ user { friends { friends { friends { ... } } } } }
  depth 1   depth 2   depth 3   depth 4

На глубине 12 с branching factor 100 (у каждого user 100 friends) число листьев — 100^12. Даже с DataLoader-батчингом это 12 батчевых запросов каждый на 10^22 ID. Depth limiting убивает это на этапе парсинга.

List-depth строже скалярной глубины. 10-уровневый запрос, где часть уровней возвращает скаляры, отличается от запроса, где каждый уровень возвращает список. Некоторые библиотеки (например, graphile/depth-limit) предоставляют отдельный maxListDepth (типично 3–4).

Complexity scoring

Complexity scoring присваивает стоимость каждому полю и суммирует по AST. Два стиля:

• Static weights: на каждое поле директива @cost(value: Int!). Анализатор обходит AST, суммирует стоимости, умножает list-поля на их аргументы limit. Отклоняет при превышении бюджета (типично: 1000–10000 единиц).
• Мультипликативная (модель GitHub): cost(parent) = cost(parent_fields) + sum(child.limit × cost(child_fields)). Запрос, запрашивающий 100 элементов на каждом из 5 уровней, стоит 100^5 по этой формуле — далеко за бюджетом, отклоняется при парсинге AST.

GitHub кепит стоимость запроса на 1000 и публикует её в extensions.cost. Shopify Storefront кепит на 1000 cost/запрос и 1000 cost/sec/IP.

Persisted queries (trusted documents)

Persisted queries (предсохранённые запросы) заменяют inline-текст запроса SHA-256-хешем. Клиент регистрирует известные запросы на сервере при сборке; во время запроса шлёт только хеш и переменные. Сервер выполняет сохранённый документ.

Это закрывает всю атакующую поверхность inline-запросов: произвольные клиентские запросы невозможны. Интроспекционная разведка, complexity-атаки, alias-бомбы и depth-бомбы блокируются на входе.

Tradeoff: каждый деплой клиента требует регистрации хешей. Ad-hoc инструменты (Postman, консоль браузера) перестают работать против production. Публичные API, которые не могут ограничить клиентов (GitHub, Shopify), оставляют inline-запросы открытыми, но добавляют complexity scoring.

Alias-бомбы и operation batching

Один документ может объявить сотни корневых алиасов для одного резолвера:

q1: user(id: 1) { email }
q2: user(id: 2) { email }
...
q1000: user(id: 1000) { email }

Это один валидный документ, но он выполняет 1000 вызовов резолверов. DataLoader сворачивает поездки в базу до одного батч-запроса — но число вызовов резолверов всё равно рычаг атакующего. Production-кепы: ≤20 root-алиасов на документ, ≤5–10 операций на batch-запрос.