CDNキャッシュの情報漏えい疑い：確認方法と初動対応

結論：配信停止・コピーの無効化・認可確認を分ける

CDN経由の画面やAPIで、別の利用者の氏名・請求情報などが表示されたら、追加の閲覧・取得を止め、情報漏えいの疑いとして社内窓口へ報告します。CDNを使っているだけでキャッシュが原因と決めつけず、応答の共有、サーバー側の認可、端末内に残った状態を分けて確認してください。

担当者は、対象の機密応答の共有配信を制限し、必要な証跡を保全しながら保存済みキャッシュの無効化を判断します。ヘッダーの変更と過去のコピーの無効化は別の作業です。再開は合成データと権限を分けたテストで判断し、過去の取得者・期間が分からない範囲は「未確認」と記録します。

対象読者： セキュリティ初心者、情シス、Web・API開発者、SaaS管理者。一般利用者の報告と、許可された管理者の調査を分けます。特定の侵害事件の報道ではなく、防御・初動対応の解説です。

情報確認日：2026年10月13日。 仕様の説明はRFC 9111、製品の挙動は各公式資料を基準にしています。設定・プラン・ブラウザ版による差があるため、その環境の現在の挙動を確認してください。

CDNキャッシュとは：応答の「控え」を複数の利用者へ返す仕組み

CDNは配信を効率化するため、応答の控えを保持して再利用することがあります。RFC 9111では、複数の利用者で再利用する共有キャッシュと、一人向けの私的キャッシュを区別しています。公開の画像と、顧客ごとの明細を同じ保存条件で扱わないことが基本です。

例えば、サーバーが顧客ごとに異なる応答を作っていても、共有キャッシュがその区別を正しく扱わなければ、異なる利用者へ同じ控えを返す原因になります。キャッシュキーは控えの識別条件、認可は誰にデータを渡してよいかの判断です。キーの工夫だけで認可を代替しません。 個別の機密応答は共有保存を避ける設計を優先します。

これはクラウドストレージの匿名公開とは異なる問題です。保存元が非公開でも、正規のアプリが返した応答を別の層で共有していないかを確認します。

読者別の影響：誰が何を確認するか

読者・担当	まず行うこと	単独で決めないこと
一般利用者・初心者	操作を止め、表示した日時・画面・自分の操作を指定窓口へ報告	他人の明細を開き直す、SNSへ画像を投稿する
情シス・CSIRT	対象、責任者、データ分類、ログ保全、封じ込めの判断を整理	一件の表示だけから被害総数や原因を断定する
Web・API開発者	認可、応答ヘッダー、URL処理、アプリ内キャッシュを照合	CDNだけを直せばサーバー側の権限も直ったと判断する
CDN・インフラ担当	実効ルール、キー、保存先、変更履歴、パージ対象を確認	応答本文を含むキャッシュを無差別に複製する
SaaS管理者・委託先窓口	提供元へ対象時刻・要求ID等を伝え、調査範囲と回答期限を取り付ける	内部設定が見えないことを「問題なし」に置き換える

利用者は原因を証明する必要はありません。秘密値や他人の個人情報を通常のメール・チャットへ広く転送せず、組織が指定する安全な経路を使います。

まず確認すること：情報漏えい疑いのチェックリスト

管理者は、既に取得した記録を起点にします。実在する他人のデータを使った追加の再現や、大量のURLへの試行は行いません。

• 検知日時とタイムゾーン、発見者、利用者自身の操作、対象機能、要求ID等を記録した。
• 個人情報、契約・請求情報、認証情報など、見えてしまったデータの種類と所有者を整理した。
• 公開ページ、ログイン後のHTML、APIのJSON、ファイル配信等のどの応答だったかを分けた。
• CDN、リバースプロキシ、アプリ内キャッシュ、ブラウザ内保存の管理者と保存範囲を確認した。
• 配信元のCache-Controlと、CDN経由の実レスポンス・実効キャッシュルールを照合した。
• CookieやAuthorizationの存在だけで、共有保存されないと判断していない。
• キャッシュキーに関係するホスト・パス・クエリ・必要なヘッダーの扱いと、配信元の解釈を照合した。
• 設定・デプロイ・ルール変更の日時と、発生時刻の前後関係を確認した。
• ログの対象、保持期間、欠落、サンプリング、CDN配信分が配信元に記録されるかを確認した。
• 未確認項目の担当者・期限と、未確認の間に止める機能を決めた。

要求ヘッダーやURLにCookie、トークン、署名付きパラメーターが含まれる場合は、共有資料にそのまま載せません。詳細証跡の保存先とアクセス権を別に管理してください。

no-cache・no-store・privateの違いと確認方法

次の表は、フィールド指定のないHTTP応答指令の要点です。CDN独自ルールやアプリ内保存まで、ヘッダー一つで制御できるとは限りません。 複数の指令と製品設定を合わせて評価します。

指令	意図する制御	初動での注意
no-cache	保存は許し、再利用前に成功した検証を要求	保存禁止ではない。再検証と利用者の認可も別
no-store	指令に従うHTTPキャッシュへの保存を禁止	以前の保存済み応答や、取得済みのコピーを消す命令ではない
private	共有キャッシュの保存は禁止し、私的キャッシュの保存は許す	ブラウザ側の保存まで禁止するものではない
public	共有保存が可能になる条件を明示	個別の機密応答へ安易に付けない。公開してよいデータかを審査
s-maxage	共有キャッシュ向けの鮮度を指定	認証済み応答に付ける場合は共有設計を慎重に確認

仕様上の根拠はRFC 9111の応答指令です。OWASPのWeb Cache Security資料も、個別応答の共有を避け、no-storeへの変更時には以前の保存分を別に扱うことを説明しています。

CloudflareのOrigin Cache Control資料では、配信元の指令とCDN側の設定の組み合わせで挙動が変わります。これは製品固有の説明で、すべてのCDNへ同じ設定手順を当てはめる根拠にはしません。

CF-Cache-StatusやAgeは手掛かりであり、無被害の証明ではない

CloudflareのCF-Cache-StatusではHITはキャッシュに応答が見つかった状態です。Ageも応答の経過時間を理解する手掛かりになります。ただし、HITだけで情報漏えいと判断せず、誰のどの内容が返ったかと組み合わせます。MISSやBYPASSを一度見ただけで、別の層や次回の要求にも問題がないとは判断できません。

初動対応：やること・やらないこと・記録すること

やること：新しい配信と保存済みコピーを別々に止める

1. 報告と対象機能の制限。 責任者へ報告し、対象の機密応答の共有キャッシュを無効にする、機能を一時停止する等の封じ込めを判断します。単にCDNを迂回して、保護されていない配信元を公開しません。
2. 必要な証跡を保全。 設定、変更履歴、要求ID、CDN・アプリ・認証のログを、取得元と時刻付きで保全します。証拠待ちで追加流出の制限を遅らせず、担当を分けて並行します。
3. 保存済みキャッシュを無効化。 対象URLだけでなく、ホスト、変種、カスタムキー、上位キャッシュ等の範囲を管理者と整理します。必要な証跡を守りつつ、緊急度に合うパージの範囲を承認します。
4. 再び保存される原因を修正。 配信元ヘッダー、CDNルール、URL解釈、認可、アプリ内キャッシュを照合します。古い応答を消しただけで、同じ条件へ戻しません。
5. 影響を調査。 データの種類、対象利用者、推定期間、過去の取得、複製先と未確認範囲を整理します。認証情報が含まれる疑いがあれば、発行元での失効・セッション対応も判断します。

Cloudflareのパージ資料では、HTTP 200は要求を受け付けたことを示し、対象内容の消去を保証する結果ではないと説明しています。また、カスタムキャッシュキーの制約によって、管理画面からの単一URLパージだけでは対応できない場合があります。各製品の公式資料で範囲を確かめ、実レスポンスでも検証してください。

やらないこと

• 原因確認のために、本番で他人のデータを開き直す・URLを広く試す。
• HAR、Cookie、トークン、個人情報入りの画面を、通常のチケットや外部サービスへ無加工で添付する。
• ログを消す、関係者全員に権限を広げる、承認なくゾーン全体のキャッシュを一括削除する。
• no-storeの追加やパージ受付成功だけで「過去の漏えいもなかった」と報告する。
• 根拠なく全員のパスワード変更だけで済ませる。データ露出と資格情報の影響は別に判断する。

記録テンプレート：秘密値を入れない共有用メモ

詳細証跡そのものではなく、対応の判断と所在を記録します。以下をチケット等へ転記し、機密の証跡は指定した安全な保存先に置いてください。

検知日時・タイムゾーン：
発見者／窓口／対応責任者：
対象サービス・機能・要求ID（秘密値を除く）：
確認済みの表示・データ分類：
未確認のこと／原因の仮説：
CDN・プロキシ・アプリ・ブラウザの確認範囲：
設定・デプロイ変更と推定期間：
証跡の取得元・保全時刻・制限された保存先：
配信制限の対象・承認・実施時刻・影響：
キャッシュ無効化の対象・方式・受付結果・実確認：
認可・ヘッダー・実効ルールの修正：
過去の取得・複製先・ログの欠落：
認証情報への影響と失効判断：
合成データでの再検証・再開承認：
連絡判断の担当／次の確認期限：

判断基準：いつエスカレーションするか

次の優先度はCyberLensによる実務整理であり、公式の被害判定や法的期限ではありません。自組織の基準と照合し、法務・個人情報保護の担当者が必要な連絡を判断します。

観測したこと	優先する判断
他人・他テナントの個人情報や機密情報が表示された／未認証でも取得できた疑い	CSIRT・責任者へ速やかにエスカレーション。対象機能の制限と証跡保全を並行
機密応答に広い共有保存の条件があり、過去の取得者や期間が分からない	調査完了待ちで通常対応にしない。保存分の無効化と影響調査の担当を決める
トークン、APIキー等の有効な認証情報まで応答に含まれた疑い	データ露出に加え発行元・権限を確認。失効・セッション制限を別の対応として判断
同一端末で古い画面が出るだけで、新規取得や他利用者への表示は未確認	ブラウザ状態と失効を分けて確認。サーバーから取得できないことは安全な環境で検証
ログがなく範囲を確定できない	無被害と結論しない。欠落期間・取得可能だった範囲・残る不確実性を報告

合成例：パージ後のMISSだけで再開しない

検証用SaaSで、合成テナントAの情報が、合成テナントBの画面へ出たとします。パージ後の最初の要求がMISSでも、次の要求で同じ控えが再利用される設定なら原因は残っています。共有保存を制限し、認可と応答の分離を直した後で、次の再開条件を確認します。これは説明用の例であり、実在の被害事例や実測結果ではありません。

復旧確認：再開前に満たす条件

許可された検証環境で、機密値のない合成データを使います。本番の被害情報を再取得して合格判定しないでください。

• 利用者AとB、別テナント、未認証の各文脈で、許可されたデータだけが返る。
• HTMLだけでなく、画面が取得するAPI・ファイルも同じ権限境界を満たす。
• 最初の要求と繰り返し要求、必要な言語・ホスト等の変種で、共有保存の制限が実効になっている。
• 設定変更後の配信元とCDN経由の応答が想定と一致し、対象の古い保存分が残っていないかを確認した。
• ログアウト・期限切れ後の新規取得が、サーバー側で拒否される。履歴からの画面復元は別に試験した。
• 正規利用、エラー応答、必要な外部連携、負荷、監視を確認した。
• ロールバックで古いキャッシュ設定や権限設定へ戻らない。
• 再開責任者、確認根拠、監視期間、未確認事項の引き継ぎを記録した。

復旧と影響調査は別の完了条件です。新しい配信が正しくなっても、過去の取得や説明・連絡の検討は継続します。

よくある誤解

HTTPSやWAFがあれば、キャッシュの情報漏えいも防げる？

HTTPSは通信経路、WAFは要求等の検査を担います。正規の応答を誤って共有する設定や、サーバー側の認可を自動で直すものではありません。WAFとファイアウォールも役割を分けて理解します。

ログアウト後の「戻る」はCDNが原因？

表示だけでは判断できません。HTTPキャッシュのほか、履歴復元用のbfcache、アプリの状態、Web Storage、Service Worker等を分けます。Chromeの公式資料は、一定条件のno-storeページでもbfcacheを利用する変更を説明しています。no-storeを「どんな履歴表示も必ず消すスイッチ」と説明しないことが重要です。

OWASPのセッション管理資料に従い、ログアウト・期限切れ時のサーバー側失効も確認します。画面の残存と、新しいデータ取得や操作が可能な状態は別ですが、共有端末で古い機密画面が見えることも対策対象です。

パージすれば、取得されたデータも取り消せる？

取り消せません。CDNの保存分を無効化しても、利用者の端末や第三者が取得したコピーまで消せるわけではありません。公開停止、保存分の対応、過去の影響調査を分けて記録します。

配信元のログに記録がないので、閲覧はなかった？

共有キャッシュから返された応答は、配信元への要求を伴わない場合があります。ログの取得範囲、保持、欠落を調べ、証跡がないことをアクセスがないことと混同しません。

関連用語・関連ページ：次に何を確認するか

目的	次のページ
社内の初動・記録・報告	漏えい疑い初動テンプレート、証拠保全の初動
データの取得権限・共有を棚卸し	SaaS権限棚卸しチェックリスト、認証と認可の違い
キャッシュの保護範囲を理解	no-store、no-cache、private、HTTP Vary、CDNパージ
他の原因を調べる	ストレージ誤公開、Webサイト改ざん、セッション乗っ取り疑い
防御の基礎から学ぶ	認証と認可のレッスン、インシデント対応
安全な演習で確認	キャッシュ保護の20問、取得済みアクセスログを読む演習

実務チェックリストは権限棚卸し、プレイブックは初動記録の補助です。キャッシュの検証をそれらだけで代替せず、本記事の担当・設定・再開条件と組み合わせて使ってください。

公式情報・参考情報

長い引用ではなく、以下の一次情報を要約しています。仕様、製品の機能、CyberLensの実務判断を区別し、変更の前には自環境の版・プラン・公式手順を確認してください。

• IETF RFC 9111: HTTP Caching — 共有・私的キャッシュ、認証済み要求、応答指令。2022年6月公開。
• OWASP: Web Cache Security Cheat Sheet — 個別応答の共有防止、キャッシュキー、保存済み応答。
• Cloudflare Docs: Origin Cache Control — 配信元の指令と実効設定の関係。
• Cloudflare Docs: Cloudflare cache responses — CF-Cache-StatusとAge。
• Cloudflare Docs: Purge cache — パージの受付と確認。
• Cloudflare Docs: Purge by single-file — カスタムキーがある場合の制約。
• Chrome for Developers: Enabling bfcache for Cache-Control: no-store — Chromeの履歴復元。2025年9月9日更新。
• OWASP: Session Management Cheat Sheet — サーバー側セッション失効。