何が起きるか
情報露出は、API応答・エラー・ログ・配信ファイルなどへ、受取人に渡す必要のない秘密情報が出てしまう問題です。
説明用に、未ログインでも初期設定済みか確認できるAPIを考えます。内部設定オブジェクト全体から、既知の秘密項目だけを除いて応答を作る例です。除外リストにapiKeyだけを登録し、後から別サービス用のserviceTokenを追加すると、その項目は除外されず応答へ残ります。ここでいう別名は、追加された別の秘密項目の名前です。攻撃者がAPIへ通常のHTTPリクエストを送り、応答JSONを読むだけでそのトークンを取得できます。
漏れたトークンが有効で、接続先のAPIがその値でデータ取得を許す構成なら、攻撃者は次にそのトークンを認証情報として提示し、別サービスの情報まで取得するおそれがあります。ただしトークンが漏れた事実と、それを使った侵入の成功は別に確認します。
正常ならどう動くか
セットアップ状態を返すAPIなら、サーバーは初期設定が完了したかなど、受取人へ公開してよい値だけを選んでHTTPレスポンスを作ります。アプリが内部で持つ設定オブジェクトには接続先や認証トークンもあるため、その全体をレスポンスへ入れません。
不備と攻撃が成立する流れ
設定オブジェクトの既知の秘密項目だけを伏せる実装を考えます。開発中に別名のトークン項目が追加されても、除外処理へ登録し忘れると、その値がHTTPレスポンスへ残ります。攻撃者が公開APIへリクエストを送り、返されたJSONを読むだけでトークンを取得できる場合があります。
デバッグ用の例外表示が接続文字列を返す場合や、Web公開領域に設定のバックアップを置いた場合も、攻撃者がURLへアクセスして内容を受け取れます。ログの閲覧権限が広すぎる場合は、そのログを読める利用者へ秘密が渡ります。情報が含まれる場所と、実際に読める相手の両方が問題です。
起こり得る被害と条件
個人情報の例では、APIの返すユーザー情報に住所や電話番号が混在し、閲覧権限のない攻撃者の端末へ届きます。この場合は、レスポンスを取得した時点で個人情報が漏えいしています。
トークンの例では、漏れた値を攻撃者が対象サービスへのHTTPリクエストの認証情報として送ります。トークンが有効で、サービスへ接続でき、その権限がデータ取得を許せば、攻撃者は対象サービスの情報も取得できます。漏えいした事実と、その値で別サービスへ侵入できた事実は区別します。
版の情報だけが出た場合は、秘密の値が漏れた場合とは被害が異なります。攻撃者がその版に合う欠陥を探す手掛かりにはなりますが、その情報だけでコード実行やログイン成功を断定できません。
防ぎ方と、防げる理由
APIの公開用の応答型を定め、初期設定完了フラグなど、公開を許した項目だけを内部設定から取り出します。内部設定へ新しい秘密項目が追加されても、公開型へ明示して加えない限り応答に入らないため、除外し忘れで漏れる経路を減らせます。 たとえば内部設定にsetupComplete、apiKey、serviceTokenがあっても、応答を{setupComplete: 内部設定の完了値}として別に組み立てます。型の宣言だけで実行時の秘密が消えるとは限らないため、実際に出力するオブジェクトも許可項目だけから作ります。
ログ・エラー・配信ファイルにも同じように秘密を出さず、バックアップや診断機能の公開範囲と閲覧権限を制限します。漏えい後は表示やファイルを消すだけでなく、対象サービスでトークンやキーを失効・再発行します。攻撃者がすでに取得した値を再送しても、照合処理が無効と判断するようにするためです。
よくある誤解
ログイン画面の裏で使うAPIが、画面と同じ認証を要求するとは限りません。画面で伏せ字になっていても、元のAPI応答に値が残っていれば読めます。秘密の別名や追加項目も確認が必要です。
実装の確認点
setup、health、debugなどのAPI、エラー表示、バックアップ、ソースマップ、CIログで、誰がどの情報を取得できるか確認します。実物の秘密を試験に使わず、識別可能なテスト値を設定して、HTTPレスポンス・ログ・生成物へ出ないことを調べます。画面の伏せ字ではなく、元の応答内容まで確認します。 ソースマップは配信用JavaScriptと元ソースの対応を持つファイルで、Web公開されていればURLから読めます。CIログは自動処理の実行記録で、実行履歴を閲覧できる相手が読めます。生成物はビルドで作るファイルや配布物なので、公開ディレクトリと配布アーカイブの中身からテスト値を探します。
出典・確認範囲
- [1] Web Security Academy: 情報露出PortSwigger / 確認日 2026-10-29