GraphQLの脆弱性診断がREST APIの診断より高額な風潮に喝！！！：2025/02/27
- 晋次 宮田
- 2025年2月27日
- 読了時間: 4分
近年、Web アプリケーション脆弱性診断にて、 GraphQLのサービスを診断するケースが増えてきました。
柔軟なクエリ言語としてのメリットが注目される一方で、「スキーマが複雑化しやすい」といった理由から、診断工数が増えるとされ、REST API よりも高額な診断料金を設定する企業もあるようです。
しかし私個人としては「GraphQL だからといって、必ずしも診断単価を上げる必要はない」という意見をもっています。
1. GraphQL が「複雑」とみなされる背景
1-1. スキーマの柔軟性と多彩な操作
GraphQL は 1 つのエンドポイントで多様なリソースを扱えるため、クエリ（読み取り）とミューテーション（書き込み）の組み合わせが増えやすいと指摘されています。
これは機能面では大きな強みですが、一方で診断時には以下のような作業が増える可能性があります。
スキーマ情報の収集：型やフィールドの一覧や関連性を把握する
権限制御の検証：ユーザーのロールや権限ごとに、どのような操作が許可されるかをチェックする
たとえば、イントロスペクション機能が有効な場合はスキーマを比較的容易に把握できますが、そうでない場合は手動で複数のクエリを試しながら調査を進めなければなりません。こうした点が、「REST API に比べて診断が複雑になりがち」という印象を与える要因になります。
1-2. ツールの対応状況
GraphQL が比較的新しい技術であることから、既存のツールは必ずしも十分に対応していない場合があるとは思います。REST API に特化したスキャナーは豊富ですが、GraphQL 特有のクエリ生成や認可テストに対応するツールはまだ限られていると思います。
元も子もないことをいいますが、そもそもツールで診断出来ないレベルを求めているから我々のような診断企業に委託するのではないでしょうか？（我々はツールはほぼ使いません。本気の鬼ペネトレーションです。）
2. なぜ「条件次第」で REST API と同一単価で足りるのか？
2-1. 診断対象の脆弱性カテゴリは本質的に共通
まず、GraphQL でも REST API でも、Web API のセキュリティ上重要となる脆弱性のポイントはほぼ同じです。たとえば、SQL インジェクションや認可の不備、情報漏えいなど、攻撃者が狙うポイントは共通しており、検証項目も重複する部分がほとんどになります。
攻撃者が引き起こそうとする被害は、大抵の場合 REST と同種の問題に起因します。GraphQL はエンドポイントが 1 つでも、そこにビジネスロジックや認可ルールが集中しているだけで、脆弱性自体が大きく変化するわけではないです。
2-2. ノウハウとツールの蓄積で工数を大幅に削減可能
GraphQL で診断工数が増えるとすれば、それはスキーマの調査や認可テストの網羅性を確保するための作業が増えるからです。しかし、弊社では、ノウハウを貯めることで、手動テストにかかる労力を削減出来ています。
イントロスペクションを使ったスキーマ解析の自動化
クエリやミューテーションの自動生成
結果的に「最終的な診断工数は REST API とさほど変わらない」状態になっています。
2-3. 大規模・複雑なシステムを除いては大差が出ない
もちろん、大規模かつスキーマが巨大で、ビジネスロジックや認可ルールが入り組んでいるようなケースでは、REST API であっても診断コストが上がりやすいのは言うまでもありません
GraphQL はそこに「複数のクエリを組み合わせてデータを取得できる」特性が加わるため、さらに注意が必要になることもあります。
ただし、「複雑さの根本原因は“API 設計や認可ルールの整理不足”であり、GraphQL だから特別に工数が跳ね上がるわけではない」はずです。逆に言えば、適切に設計された中規模以下のプロジェクトであれば、REST API と同様の単価でも十分な診断が行えるわけです。
3. 弊社の見解：GraphQL「だけ」で単価を上げる必要はない
以上を踏まえ、私はGraphQL だからといって常に診断単価を上げる必要はないと考えています。
とはいえ、あまりにも巨大なスキーマや統一されていない認可ロジックなど、複雑度が高い案件では追加工数が発生する場合があります。ただしその原因の多くは、スキーマやビジネスロジックの整理不足にあると言えます。そういったケースでは、GraphQL であろうと REST API であろうと、同程度の手間がかかるケースが多いです。
4. まとめ
「GraphQLだから追加料金ね」 という見積もりは我々はしません。
