Защита GraphQL: стоимость запроса, глубина и федерация

Почему GraphQL нужна защита, которой не нужно REST

В REST форму каждого ответа владеет сервер. GET /users/42/friends возвращает ограниченную страницу; стоимость этого эндпоинта фиксирована и известна в момент написания. Клиент не может попросить /users/42/friends/friends/friends — такого маршрута нет, и чтобы получить вложенные данные, клиент обязан сделать больше отдельно лимитируемых запросов.

GraphQL переворачивает это. Запрос составляет клиент — он выбирает поля, глубину и ширину в одном запросе. Эта выразительность — главная фича, и она же — поверхность атаки: клиент может попросить произвольно глубокие, произвольно широкие, рекурсивные данные одним HTTP-вызовом, и сервер послушно их зарезолвит. Самоссылочный тип вроде User.friends: [User] позволяет запросу вкладываться сам в себя, пока ответ не станет комбинаторным взрывом. Один запрос, без авторизации, превращается в миллионы вызовов резолверов и обращений к БД. Это DoS-вектор, уникальный для выставленного наружу GraphQL-эндпоинта, и потому публичному GraphQL API нужны защиты выполнения, которые REST API получает бесплатно от своих фиксированных маршрутов.

Защита многослойная, и слои работают до выполнения — ты отклоняешь вредоносный запрос на этапе валидации, а не переживаешь его.

Контроль 1 — лимит глубины

Первая защита ограничивает, насколько глубоко может вкладываться запрос. Правило валидации обходит AST запроса и отклоняет любую операцию, чьё множество выборки вложено глубже максимума — обычно 7–10 уровней для реального приложения. Именно это останавливает бомбу рекурсивных друзей: friends { friends { friends { ... } } } превышает лимит глубины и отклоняется на валидации, до того как запустится хоть один резолвер.

// main.ts — wire a depth-limit validation rule into Apollo's validationRules
import depthLimit from 'graphql-depth-limit';

GraphQLModule.forRoot<ApolloDriverConfig>({
  driver: ApolloDriver,
  // any operation nested deeper than 7 selection sets is rejected at validation
  validationRules: [depthLimit(7)],
});

Лимит глубины дёшев, статичен и ловит самую очевидную рекурсию. Но у него есть слепое пятно, и это слепое пятно — следующий контроль.

Контроль 2 — сложность / анализ стоимости запроса

Запрос может быть неглубоким и всё равно разрушительным. users(first: 10000) { posts(first: 1000) { comments(first: 1000) } } — это всего три уровня в глубину, он проскальзывает мимо любого лимита глубины, — но умножается примерно до десяти миллиардов узлов. Лимит глубины считает вложенность; он слеп к ширине и к множителям пагинации.

Анализ стоимости это чинит. Ты назначаешь числовую сложность каждому полю — скалярные поля дёшевы, поля-списки дороги, а стоимость поля-списка умножается на его аргумент пагинации, — затем суммируешь стоимость всего запроса до выполнения и отклоняешь всё, что превышает бюджет (обычно 1000). NestJS поддерживает это через плагин сложности, считающий оценку по per-field эстиматорам или значению complexity на поле.

// Аннотируй дорогое поле и умножай на аргумент пагинации
@Field(() => [Post], { complexity: 5 })
posts: Post[];

// A plugin sums the query's complexity at validation time and rejects over budget
import { ComplexityPlugin } from './complexity.plugin'; // computes score, throws over maxComplexity (e.g. 1000)

Эстиматор для пагинированного списка умножает базовую стоимость поля на first/limit, так что users(first: 10000) набирает 10000× стоимости на пользователя и сам по себе пробивает бюджет. Это контроль, который ловит широкую-но-неглубокую бомбу, которую лимит глубины пропускает. Нужны оба: глубина против рекурсии, стоимость против fan-out.

Контроль 3 — persisted-запросы (сильнейший рычаг)

Предыдущие два контроля ограничивают произвольный запрос. Persisted-запросы меняют игру, убирая произвольность. Вместо приёма любой строки запроса клиент шлёт хеш запроса, зарегистрированного заранее; сервер ищет хеш и выполняет только ту операцию, которую уже знает. Automatic Persisted Queries (APQ) делают это в первую очередь чтобы уменьшить полезную нагрузку запроса — клиент шлёт короткий хеш вместо длинной строки запроса.

Выигрыш в безопасности приходит от запуска persisted-запросов в режиме allow-list: сервер выполняет только операции из проверенного, заранее зарегистрированного набора и отклоняет любой хеш, которого не видел. В этом режиме DoS произвольным запросом устраняется напрочь — атакующий не может прислать бомбу рекурсивных друзей, потому что сервер не запустит запрос, не выданный ему на этапе сборки. Цена — гибкость: публичный или сторонний API, чьи клиенты законно составляют новые запросы, не может занести их в allow-list. Для first-party-приложения — твоих собственных веб- и мобильных клиентов, поставляющих фиксированный известный набор операций, — allow-list persisted-запросы — единственный сильнейший рычаг защиты, и они складываются с лимитами глубины и стоимости как defense in depth.

Рантайм-родственник: N+1 и DataLoader

Анализ стоимости ограничивает то, что клиент может попросить; он ничего не говорит о том, что твои резолверы на самом деле делают, отвечая. Fan-out резолверов заново вносит проблему N+1 — резолвинг списка из N родителей с одним дочерним запросом на родителя, — которую (как разбиралось ранее в этом юните) DataLoader решает, батчируя N чтений в одно и кешируя на запрос. Думай о них как о паре: лимит стоимости — статический бюджет на форму запроса, DataLoader — рантайм-бюджет на работу резолверов. Защищённому API нужны оба, потому что запрос, прошедший ворота стоимости, всё равно может выдать N+1 запросов, если его резолверы наивны.

Федерация — когда единый граф становится узким местом

Контроли выше защищают один граф. Приходилось ли ждать ревью схемы от другой команды, прежде чем отгрузить собственный тип? Именно этот беспорядок владения призвана растворить федерация. По мере роста графа единая монолитная схема и набор резолверов становятся узким местом деплоя — каждая команда правит один файл, каждое изменение — полный передеплой. Apollo Federation (в NestJS — ApolloFederationDriver) разбивает граф между сервисами. Каждый сабграф владеет своими типами, помечает сущности, которыми владеет, через @key(fields: "id") и предоставляет резолвер __resolveReference, чтобы другие сабграфы могли расширять его сущности по ссылке. Шлюз (gateway) композирует сабграфы в один суперграф и планирует кросс-сервисные запросы, доставая поля каждой сущности из сабграфа-владельца.

# users subgraph — owns the User entity, identified by id
type User @key(fields: "id") {
  id: ID!
  name: String!
}

# reviews subgraph — extends User by reference, adds the fields it owns
type User @key(fields: "id") {
  id: ID! @external
  reviews: [Review!]!   # resolved here via __resolveReference(id)
}

Это современный декларативный преемник более старого schema stitching, где шлюз вручную сливал схемы, а кросс-сервисную обвязку ты писал руками. Федерация делает связи декларативными — @key и __resolveReference — и позволяет шлюзу планировать запрос. Критически: защита не переезжает на шлюз и не останавливается там — лимиты глубины, анализ стоимости и persisted-запросы по-прежнему живут на краю, потому что суперграф ровно так же композируем — а значит ровно так же уязвим, — как единый граф, который он заменил.