午前I問題

WebサービスがAPIを外部に公開する際のセキュリティ対策に関する記述のうち、最も適切なものはどれか。

ア）APIキーをURLのクエリパラメータに含めて送信すれば、HTTPS通信であっても第三者に漏洩する経路はない

イ）APIの利用者認証にはAPIキーやOAuth 2.0アクセストークン等を用い、加えてレート制限を設けることで、総当たり攻撃や過剰なリクエストによる影響を軽減できる

ウ）内部システムからのみ呼び出されるAPIであれば、外部公開APIと異なり認証・認可の実装は不要である

エ）APIのエンドポイントURLを推測困難な文字列にすることで、認証機構を省略しても安全性が確保できる

午前I の解答・解説を見る

正解： イ）APIの利用者認証にはAPIキーやOAuth 2.0アクセストークン等を用い、加えてレート制限を設けることで、総当たり攻撃や過剰なリクエストによる影響を軽減できる

解説：

  • ア）不正解。URLのクエリパラメータはブラウザ履歴・プロキシログ・Webサーバのアクセスログ・Refererヘッダ経由で第三者に渡る可能性があり、HTTPSであっても漏洩経路は複数存在する。APIキーはヘッダで送信すべき。
  • イ）正解。認証（APIキー・OAuth 2.0トークン等）に加え、レート制限（Rate Limiting）を設けることで、ブルートフォース攻撃やDoS的な過剰リクエストによる影響を軽減できる。API公開における基本的な多層防御の考え方。
  • ウ）不正解。内部ネットワークであっても、内部不正や侵入後の横展開（ラテラルムーブメント）のリスクは存在するため、ゼロトラストの観点から内部APIにも認証・認可は必要（多層防御）。
  • エ）不正解。「推測困難なURL」に依存する安全性は「隠蔽によるセキュリティ（Security through Obscurity）」であり、真の認証機構の代替にはならない。URLはログや共有により漏洩し得る。

午前II問題

OWASP API Security Top 10における「BOLA（Broken Object Level Authorization：不適切なオブジェクトレベル認可）」の説明として、最も適切なものはどれか。

ア）APIエンドポイントへの過剰なリクエスト送信により、サービスを停止に追い込む攻撃

イ）ユーザが認証は済んでいるものの、リクエストパラメータのID値を変更することで、本来アクセス権限のない他ユーザのオブジェクト（データ）にアクセスできてしまう脆弱性

ウ）SQL文の組み立てにユーザ入力を直接連結することで発生するインジェクション脆弱性

エ）APIサーバのTLS証明書の検証を省略することで発生する中間者攻撃のリスク

午前II の解答・解説を見る

正解： イ）

解説：

  • ア）不正解。これはレート制限の欠如（Unrestricted Resource Consumption）に relate する説明であり、BOLAとは異なる項目。
  • イ）正解。BOLAはOWASP API Security Top 10で長年1位に挙げられる代表的脆弱性。例えばGET /api/orders/1001のようなAPIで、認証済みユーザが1001を1002に書き換えるだけで他人の注文情報を閲覧できてしまうケースが典型例。APIサーバ側で「リクエストされたオブジェクトの所有者が、認証されたユーザ本人と一致するか」の検証（オブジェクトレベル認可）が欠落していることが原因。
  • ウ）不正解。SQLインジェクションの説明であり、BOLAとは別の脆弱性カテゴリ。
  • エ）不正解。TLS証明書検証不備による中間者攻撃の説明であり、通信経路の脆弱性でありオブジェクトの認可制御の不備とは異なる。

午後問題

社内向け経費精算システムを提供するE社は、フロントエンドとバックエンドをGraphQL APIで接続するシステムを新規開発した。リリース前のセキュリティレビューで、次の点が指摘された。

  • クライアントからのGraphQLクエリで、任意のフィールドを指定してユーザ情報を取得できるuserクエリが実装されており、user(id: 5) { name, email, salary, socialSecurityNumber }のように、本来経理担当者以外は参照すべきでないsalary（給与）やsocialSecurityNumber（マイナンバー相当）フィールドまで、認可チェックなしに一般社員が取得できてしまう
  • クエリの深さ（ネスト）に制限がなく、user { manager { manager { manager { ... } } } }のように深くネストしたクエリを送信すると、サーバ側の処理負荷が指数関数的に増大する
  • REST APIと異なりエンドポイントが/graphqlの1つに集約されているため、WAFのURLベースのルールでは細かい制御ができていなかった

設問1

salaryやsocialSecurityNumberフィールドへの不適切なアクセスを防ぐために、GraphQL APIの実装として講じるべき対策を述べよ。

設問1の解答・解説を見る

正解例： GraphQLのスキーマ定義やリゾルバ（resolver）レベルで、フィールド単位の認可チェックを実装する。具体的には、salaryやsocialSecurityNumberといった機微なフィールドを解決するリゾルバ内で、リクエストしたユーザのロール（経理担当者権限の有無）を検証し、権限がない場合はそのフィールドをnullとして返す、またはクエリ自体をエラーとして拒否する。GraphQLはクライアントが自由にフィールドを組み合わせられる性質上、REST APIのようにエンドポイント単位の認可では不十分であり、フィールドレベル（オブジェクトプロパティレベル）の認可制御が必須となる。

解説・採点基準（計15点）：

採点項目キーワード配点
フィールドレベル（リゾルバレベル）の認可チェックに言及「フィールド単位」「リゾルバでの認可」7点
ロールに基づくアクセス制御に言及「経理担当者のみ」「ロールベース」4点
GraphQL特有の課題（自由なフィールド選択）への言及「クライアントが任意のフィールドを指定できる」「エンドポイント単位の認可では不十分」4点

これは過剰なデータ露出（Excessive Data Exposure、OWASP API Security Top 10の一項目）にも relate する。この用語への言及があれば加点対象とする。

設問2

クエリの深いネストによるサーバ負荷増大への対策を2つ挙げよ。

設問2の解答・解説を見る

正解例：

  1. クエリの深さ制限（Depth Limiting）：GraphQLサーバのミドルウェアで、受け付けるクエリのネスト階層数に上限（例：5階層まで）を設け、それを超えるクエリはパース時点で拒否する。
  2. クエリの複雑度制限（Query Complexity / Cost Analysis）：各フィールドにコストを割り当て、クエリ全体のコスト合計が閾値を超える場合に実行を拒否する。深いネストや大量のリスト取得を組み合わせた過剰なクエリを防止できる。

解説・採点基準（計15点）：

採点項目キーワード配点
深さ制限（Depth Limiting）に言及「ネスト階層の上限」「深さ制限」6点
クエリ複雑度・コスト制限に言及「クエリコスト分析」「複雑度制限」6点
その他有効策（タイムアウト設定、レート制限等）への言及「実行時間の上限」「レート制限」3点（上記2つと合わせて上限15点）

「GraphQLをやめてRESTに戻す」という回答は既存システムの全面書き換えを伴う過大な対応であり、設問が求める実装レベルの対策として不適切なため得点対象外とする。

重要キーワード

用語説明
APIセキュリティREST/GraphQL等のAPIが持つ認証・認可・入力検証等のセキュリティ上の考慮点全般
BOLA（Broken Object Level Authorization）認証は正しくても、リクエスト対象オブジェクトへのアクセス権限検証が欠落している脆弱性。OWASP API Security Top 10の代表格
過剰なデータ露出APIレスポンスにクライアントが必要としない機微情報まで含めてしまう問題。フィールドレベルの制御不足が原因となることが多い
クエリ深さ制限GraphQL APIにおいて、ネストしたクエリの階層数に上限を設けることでサーバ負荷の急増を防ぐ対策
レート制限一定時間内のリクエスト数に上限を設け、総当たり攻撃やリソース枯渇攻撃を抑制する仕組み
フィールドレベル認可エンドポイント単位ではなく、レスポンスに含まれる個々のフィールド単位でアクセス権限を検証する制御方式

まとめ

  • 午前I視点： API公開時は認証（APIキー・OAuth 2.0）とレート制限を組み合わせるのが基本。URLの隠蔽や内部APIだからという理由での認証省略は不適切。
  • 午前II視点： OWASP API Security Top 10のBOLAは、認証済みでもオブジェクト単位の認可検証が欠落している脆弱性であり、ID書き換えによる他者データアクセスが典型例。
  • 午後視点： GraphQL特有のリスクとして、フィールドレベルの過剰なデータ露出と、クエリの深いネストによる負荷増大があり、それぞれリゾルバでの認可チェックと深さ・複雑度制限で対策する。