如何保护 GraphQL API 免受滥用型查询的攻击？

Question

IT Interview Practice · Accepted Answer

让 GraphQL 强大的灵活性，也让它成为一个 **DoS 攻击面**：客户端可以在一次调用里深度嵌套查询，或请求巨大的列表。你分层防御——**深度限制、复杂度/成本分析、限流以及恰当的鉴权**——而这些查询语言本身都不会替你强制执行。

## 威胁：无界查询

```graphql
# 一个恶意的循环查询：每一层都让工作量呈指数增长
query Bomb {
  user { friends { friends { friends { friends { name } } } } }
}
```

## 防御手段

- **深度限制** —— 拒绝嵌套超过（比如）7 层的查询。廉价的第一道防线。
- **成本/复杂度分析** —— 给每个字段分配一个成本，按列表字段的 `first` 参数加权，若总量超过预算就在执行前拒绝。比单纯的深度更强，因为它考虑了列表的宽度。
- **限流** —— 按客户端设预算，理想情况下基于**查询成本**（而不仅是请求数），这样一个昂贵查询就抵得上很多次。
- **持久化/白名单查询** —— 在生产中，只接受一组预先注册的查询；任意的临时查询被拒绝，从而消除大多数注入/DoS 向量。

```js
import depthLimit from "graphql-depth-limit";
import costAnalysis from "graphql-cost-analysis";

const server = new ApolloServer({
  schema,
  validationRules: [
    depthLimit(7),                                  // 阻止深度嵌套
    costAnalysis({ maximumCost: 1000 }),            // 在执行前阻止宽泛/昂贵的查询
  ],
});
```

## 鉴权

认证一次（在 `context` 中校验 token），然后**按字段/resolver 授权**——绝不要指望客户端省略字段。在 resolver 中或像 GraphQL Shield 这样的一层里做检查，并且**绝不要在生产中暴露 introspection schema** 或冗长的堆栈跟踪。

## 为什么这很重要

REST endpoint 天然是有界的；单个 GraphQL 查询则不是。高级面试官想要**基于成本**的思维方式——深度是必要但不充分的，复杂度分析加持久化查询才是真正的答案——以及按 resolver 授权的纪律。

威胁：无界查询

相关问题

防御手段

鉴权

为什么这很重要