GraphQL APIで「一部だけの個人情報露出」が重大インシデントになり得る理由

はじめに

GraphQLは柔軟なAPI設計が可能である一方で、
「本来返却されるべきではないフィールド」が露出しやすい構造でもある。

今回は、バグバウンティ調査中に遭遇した「firstNameのみが完全表示されていたケース」をベースに、
なぜ“たった一部の情報”でもセキュリティリスクになり得るのかを解説する。

※ 本記事は実際の調査経験を元に一般化・匿名化した内容である。
対象サービス名・ユーザー情報・識別子等はすべてマスクしている。

発見した問題

あるGraphQL APIにおいて、本来はイニシャル表示のみを想定していたユーザー情報が、
APIレスポンス上では完全な firstName として返却されていました。

想定されていた表示

{
  "firstName": "H.",
  "lastName": "D."
}

実際のレスポンス

{
  "firstName": "Hogehoge",
  "lastName": "D."
}

lastName側はマスクされていた一方で、firstNameのみ完全表示されていたため、
privacy masking が片側だけ実装されている状態でした。

なぜ危険なのか？

一見すると、

「firstNameだけなら大したことないのでは？」

と思われるかもしれない。

しかし実際の攻撃では、“単体情報”ではなく“情報の相関”が重要になる。

今回のケースでは、以下のような情報を組み合わせることが可能であった。

firstName
ユーザーUUID
avatar URL
レビュー履歴
投稿店舗情報

これにより、同一人物のレビュー活動を追跡できる状態となっていた。

攻撃者視点で見るとどうなるか

1. 同一人物の追跡

UUIDが固定で返却されていたため、複数レビューを横断して同一人物を追跡可能であった。

例:

東京の高級レストラン
横浜のバー
大阪旅行時の店舗

などを時系列で紐付け可能になります。

2. 実在人物の特定

avatar画像やレビュー内容を組み合わせることで、SNSアカウントやGoogleプロフィールと関連付けられる可能性がある。

特に:

ニックネーム
顔写真
行動パターン
利用地域

が重なると、現実の人物特定に繋がるケースがあります。

3. ソーシャルエンジニアリング

以下のような情報が揃うと、標的型攻撃の材料になります。

よく利用する地域
趣味嗜好
食事傾向
活動時間帯

つまり、単なる「名前漏洩」ではなく、“ユーザープロファイリング”が可能となる。

なぜGraphQLで起きやすいのか

GraphQLでは、クライアント側が必要フィールドを自由に指定できます。

例えば:

query {
  reviews {
    reviewer {
      id
      firstName
      lastName
    }
  }
}

この柔軟性は便利である一方、サーバー側で適切なフィールド制御を行わない場合、
「フロントでは非表示想定だった情報」がAPI経由で露出する。

よくある実装ミス

フロントエンド側のみでマスク

const masked = user.firstName[0] + ".";

この場合、API自体はフルデータを返却しているため、
GraphQL ExplorerやDevToolsから容易に確認可能となる。

どうすれば防げるのか

今回のような問題を防ぐためには、フロントエンド側ではなく、APIレベルでの制御が必要となる。

1. APIレスポンス側でマスキングを行う

フロントエンド側のみでマスキングを実施すると、GraphQL API自体からはフルデータが取得できてしまう。

そのため、以下のようにサーバー側で加工済みデータを返却するべきである。

{
  "firstName": "H.",
  "lastName": "D."
}

2. 不要なフィールドを返却しない

GraphQLでは「取得可能であること」自体がリスクになる。

そのため:

avatar URL
internal UUID
tracking可能な識別子
internal metadata

などは、本当に必要な場合のみ返却すべきである。

3. Field-level authorization を導入する

GraphQLでは、Query単位だけでなくField単位での認可制御が重要となる。

例えば:

未認証ユーザー
一般ユーザー
管理者

で取得可能フィールドを分離する必要がある。

4. 「組み合わせ」を前提に設計する

セキュリティレビューでは、単体データだけではなく、
「他データと組み合わせた時に何が起こるか」を考慮する必要がある。

特に:

UUID
avatar
行動履歴
location情報

などは相関分析されやすい。

privacy-by-designの観点からも、最小限の情報返却を徹底すべきである。

実際の評価で印象的だったこと

今回興味深かったのは、露出していた情報自体は一見すると限定的に見えた点である。

{
  "firstName": "Hogehoge",
  "lastName": "D."
}

しかし実際には、

UUID
avatar URL
review履歴
restaurant情報

などと組み合わせることで、ユーザーの行動追跡や実在人物との関連付けが可能な状態となっていた。

結果として、この問題は実際のバグバウンティプログラム上で高い優先度(P2)として扱われた。

ここで重要だったのは、

「漏えいしている情報の量」

ではなく、

「その情報が攻撃者にどう利用されるか」

である。

セキュリティレビューでは、
単体では些細に見える情報でも、
相関分析やOSINTと組み合わせることで重大インシデントにつながるケースが存在する。

学んだこと

今回のケースで重要だったのは、
「単体では弱く見える情報でも、組み合わせると高リスクになる」という点である。

セキュリティでは、

情報の量

よりも、

情報同士の関連性
攻撃者がどう利用できるか

の方が重要になるケースがある。

特にGraphQLでは、

過剰なフィールド返却
hidden field exposure
フロント依存のマスキング

が発生しやすいため注意が必要である。

まとめ

今回のような問題を防ぐためには、フロントエンド側ではなく、APIレベルでの制御が必要となる。

1. APIレスポンス側でマスキングを行う

フロントエンド側のみでマスキングを実施すると、GraphQL API自体からはフルデータが取得できてしまう。

そのため、以下のようにサーバー側で加工済みデータを返却するべきである。

{
  "firstName": "H.",
  "lastName": "D."
}

2. 不要なフィールドを返却しない

GraphQLでは「取得可能であること」自体がリスクになる。

そのため:

avatar URL
internal UUID
tracking可能な識別子
internal metadata

などは、本当に必要な場合のみ返却すべきである。

3. Field-level authorization を導入する

GraphQLでは、Query単位だけでなくField単位での認可制御が重要となる。

例えば:

未認証ユーザー
一般ユーザー
管理者

で取得可能フィールドを分離する必要がある。

4. 「組み合わせ」を前提に設計する

セキュリティレビューでは、単体データだけではなく、
「他データと組み合わせた時に何が起こるか」を考慮する必要がある。

特に:

UUID
avatar
行動履歴
location情報

などは相関分析されやすい。

privacy-by-designの観点からも、最小限の情報返却を徹底すべきである。

まとめ

今回のケースでは:

firstName
UUID
avatar
review history

を組み合わせることで、単なる表示ミスではなく、
「個人追跡・プロファイリング」に繋がるリスクが存在していました。

GraphQLを利用する場合は、- APIレベルでのマスキング

必要最小限のフィールド返却
フィールド単位の認可制御
privacy-by-design

を徹底することが重要である。

おわりに

バグバウンティを始めた当初は、
「Criticalな脆弱性を見つけないと意味がない」と考えていました。

しかし実際には、

情報をどう組み合わせるか
攻撃者視点でどう見えるか
その情報が何に悪用されるか

を考えることの方が、はるかに重要であると感じた。

特にGraphQLは、
「便利さ」と「情報露出」が非常に近い場所に存在するため、
今後も継続的に研究していきたい分野である。