不正なクエリから GraphQL API をどう守るのか?

Question

IT Interview Practice · Accepted Answer

GraphQL を強力にする柔軟性は、同時にそれを **DoS の攻撃面** にもします: クライアントはクエリを深くネストさせたり、1 回の呼び出しで巨大なリストを要求したりできます。**深さ制限、複雑度/コスト分析、レート制限、適切な認証** という層で防御します — これらのいずれもクエリ言語が自動で強制してくれるものではありません。

## 脅威: 無制限のクエリ

```graphql
# A malicious cyclic query: each level multiplies the work exponentially
query Bomb {
  user { friends { friends { friends { friends { name } } } } }
}
```

## 防御

- **深さ制限** — 例えば 7 レベルを超えてネストされたクエリを拒否します。安価な第一の防衛線です。
- **コスト/複雑度分析** — 各フィールドにコストを割り当て、リストフィールドはその `first` 引数で重み付けし、合計が予算を超えたら実行前に拒否します。リストの幅を考慮するため、素の深さ制限より強力です。
- **レート制限** — クライアントごとの予算、理想的には (リクエスト数ではなく) **クエリコスト** に対して設定し、1 つの高価なクエリが多数分としてカウントされるようにします。
- **Persisted/許可リスト化されたクエリ** — 本番環境では事前登録されたクエリのセットのみを受け付け、任意のアドホッククエリは拒否します。これでほとんどのインジェクション/DoS のベクトルを排除できます。

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

const server = new ApolloServer({
  schema,
  validationRules: [
    depthLimit(7),                                  // block deep nesting
    costAnalysis({ maximumCost: 1000 }),            // block broad/expensive queries pre-execution
  ],
});
```

## 認証

1 度認証し (`context` でトークンを検証)、その後 **フィールド/リゾルバごとに認可** します — クライアントがフィールドを省略することを決して信用しないでください。チェックはリゾルバ内、または GraphQL Shield のような層で行い、本番環境で **イントロスペクションスキーマを公開したり** 詳細なスタックトレースを出したりは決してしないでください。

## なぜ重要なのか

REST のエンドポイントは自然に境界が定まっていますが、1 つの GraphQL クエリはそうではありません。シニアの面接官は **コストベース** の考え方を求めます — 深さは必要だが不十分であり、複雑度分析に persisted query を加えたものが本当の答えです — そしてリゾルバごとの認可という規律を求めます。

脅威: 無制限のクエリ

防御

認証

なぜ重要なのか

関連する質問