目次
会員ページはログインを確認しているのに、別の利用者へ前の人の情報が表示される。アプリの認可が正しくても、手前の共有キャッシュが本人確認を経由せず保存済みの応答を返せば、利用者の境界が崩れる場合があります。速く表示する設計と、誰へ返してよいかを一緒に確認することが必要です。
本記事は2026年10月18日にMDNとOWASPの一次資料を確認した実務解説です。特定製品の新規脆弱性の速報ではありません。会員画面の構成は仮想例で、分類表と試験手順は本サイトの提案です。既存のキャッシュ更新の記事とは分け、個人情報を共有しないための設計を扱います。
スポンサーリンク
ブラウザーと共有キャッシュを分けて考える
ブラウザー側のキャッシュと、CDNやリバースプロキシなどの共有キャッシュでは、同じ応答が届く相手が違います。本人のブラウザーへ保存することを許す設計でも、別の利用者と共有してよいわけではありません。
最初に、アプリから利用者までの間で応答を保存する層を一覧にします。CDN、プロキシ、アプリ内部の結果キャッシュ、Service Workerなどがある場合、どこでどのキーを使って保存するかを分けます。すべての層が同じHTTPヘッダーだけに従うとは限りません。
本サイトは、ページ単位ではなく応答に含まれる情報で分類する方法を勧めます。商品ページでも、ログイン中だけ氏名や契約別価格を埋め込むなら、匿名向けの公開応答と同じ扱いにはできません。
出典：MDN HTTP caching。
private・no-store・no-cacheの役割を混同しない
MDNは、privateが共有キャッシュでの保存を制限することと、no-storeが保存を避けるための指定であることを説明しています。一方、no-cacheは保存そのものの禁止ではなく、再利用の前に検証を求める指定です。名称の印象だけで選ばないことが重要です。
本人のブラウザーへ保存してもよいが他人と共有したくない応答と、保存自体を避けたい機微な応答では、求める条件が異なります。業務上の機密性、最新性、使い勝手を考え、必要な制御を選びます。すべてのページへ思い付く指定を並べれば安全になるわけではありません。
管理されたCDNでは、独自の保存ルールがヘッダーの扱いを変える場合があります。アプリがno-storeを返しているから確認は不要とせず、利用中の提供元のルールと実際の応答を調べます。
スポンサーリンク
キャッシュキーに含まれない違いは共有され得る
キャッシュキーは、どの要求を同じ保存内容として扱うかの基準です。URLが同じでも、利用者、契約、言語などで応答が変わる場合、その違いが保存と再利用の条件に反映されているかを確認します。
ただし、個人情報を含むすべてのページをCookieごとに共有キャッシュへ分けて保存することが、常に適切な解決とは限りません。不要な共有保存をやめる、公開部分と個別部分を分離するなど、構造を単純にする方法も検討します。
Varyは要求ヘッダーによって応答が変わる場合の重要な情報ですが、利用製品のキー設定や保存条件と整合させる必要があります。Varyを追加しただけで、認可や秘密の扱いを代替したことにはなりません。
URLの見え方が層ごとに違う問題も調べる
アプリは会員ページとして処理し、CDNは静的な資源だと思って保存するような解釈差があると、意図しない共有につながる場合があります。OWASPのWeb Cache Security資料は、こうした保存条件やキー、正規化の問題を扱っています。
本サイトは、拡張子だけで保存を決める設定や、存在しないパスも同じ会員画面へ返すルーティングを確認することを勧めます。未知のURLへ何を返すかをアプリとCDNでそろえ、機微な応答を静的ファイルのように扱わないようにします。
クエリ文字列、転送ヘッダー、ホスト名の扱いも確認します。応答を変える値がキーから抜けていれば、別の要求へ影響する可能性があります。任意の入力をキーへ全部加える前に、その入力を受け付ける必要性と正規化のルールを見直してください。
関連する公式仕様：OWASP Web Cache Security Cheat Sheet。
スポンサーリンク
ログアウトはキャッシュ済みの応答の消去とは違う
ログアウトでセッションが失効しても、過去に保存された応答が自動で消えるとは限りません。ブラウザーの戻る操作で見える内容が、手元の表示か、新しい通信で返された情報かを分けて確認します。
MDNは、新しくno-storeを返しても、すでに保存された同じURLの応答を削除することにはならないと説明しています。過去の誤保存がある場合は、保存の停止に加え、提供元の方式に沿った削除や更新が必要です。
すでに他人へ配信された情報を、設定変更で回収できるわけではありません。漏えいが疑われる場合は、対象、期間、返した情報、アクセスの記録を調べ、単なる表示不具合と決め付けないようにします。
二つのアカウントと未ログインで試験する
仮想の会員サイトなら、専用アカウントAとBに見分けられる架空のプロフィールを設定します。Aで対象のURLを読み、次に別のブラウザーや分離したセッションでBとして同じURLを開きます。最後に未ログインでも確認します。
ブラウザーの保存状態を消しただけで共有キャッシュを検証したつもりにならないようにします。CDNの応答やアプリのログを必要な範囲で照合し、アプリへ届いた要求と保存済みの応答を区別します。見た目だけでなくレスポンスの内容を確認します。
試験には実際の利用者の情報を使わず、自分の管理範囲の経路で行います。キャッシュを広く削除する操作は負荷に影響するため、通常利用者への影響を避けた検証環境と対象範囲を用意します。
| 応答の種類 | 設計する方針 | 確認する相手 |
|---|---|---|
| 匿名向けの公開情報 | 条件を定めて共有できる | ログイン有無で秘密が混ざらない |
| 会員別のプロフィール | 共有保存を許可しない | 別会員と未ログインへ返らない |
| 保存を避けたい機微な情報 | 保存不可の扱いを各層で確認 | ブラウザーとCDNの両方 |
| 利用者別のAPI結果 | キーと保存範囲を明確にする | 同じURLを別資格情報で読む |
変更前に既存の誤保存を想定する
改修では、今後の保存を止める変更と、既存の内容を取り除く作業を分けます。保存が止まっていない段階で削除だけを繰り返すと、また同じ内容を共有する可能性があります。アプリとCDNの設定を確認したうえで、対象の削除と再検証を行います。
全体を一括でキャッシュ対象外にする暫定策は、安全側へ寄せる助けになる場合がありますが、オリジンの負荷を増やします。停止を防ぐための容量と監視を確認し、公開情報だけを適切に再開する手順を用意します。
切り戻しで古い危険な保存ルールを復活させないよう、性能の改善と機密性の条件を別々に記録します。速くなったことだけで変更を完了としないことが重要です。
公開ページの一部分だけが個別になるケース
仮想の商品ページで、匿名の閲覧者には共通の価格を返し、会員には契約別の価格を返すとします。URLが同じだからという理由でHTML全体を共有すると、最初に保存された会員向けの内容が別の人へ届く可能性があります。個人情報は氏名だけではなく、利用者ごとの契約条件や注文状態も含むものとして分類します。
本サイトの提案は、公開時とログイン時で何が変わるかを画面ごとに記録することです。本文だけでなく、ナビゲーションの名前、通知件数、HTMLへ埋め込む初期データ、構造化した情報も対象にします。見える画面が同じでも、応答のソースへ秘密が残っていないかを確認します。
ログイン判定のためにCookieが付いていることと、その応答が共有されないことは別です。CDNがすべてのCookieを保存条件へ反映するとは限りません。何をもって公開応答として扱うかを設定と実際の返答で照合してください。
スポンサーリンク
エラーと転送のキャッシュも点検する
正常なHTMLだけを確認すると、エラー応答や転送で返す情報を見落とします。たとえば、利用者ごとの状態を含むエラーページや戻り先を、共通の応答として保存してよいかを判断します。応答コードだけを一律の保存条件にしないようにします。
権限変更や契約解除の後も、保存した内容を同じ条件で再利用してよいとは限りません。どの操作で失効や再検証が必要かを明記し、更新の経路とキャッシュの削除を対応付けます。キャッシュキーへ資格情報そのものを入れて調査を簡単にする方法は避け、秘密を含まない内部の識別と必要な認可を使います。
公開部分と個別部分を分離する選択肢
同じHTMLへ公開の記事と個別の通知を埋め込む設計では、応答全体の扱いが複雑になります。公開部分を共有し、個別情報を認証と認可を経た別の応答で取得する構成も候補です。ただし、そのAPIの保存ルールが適切であることまで含めて設計します。
分離すると要求数が増えたり、表示の順序が変わったりするため、実際の利用環境で測定します。設計の都合で一時的に利用者名が別人のものに切り替わるような状態も避けます。フロントエンドの状態管理とキャッシュの所有者をそろえてください。
キャッシュは速度の機能であると同時に、情報を再配布する仕組みです。どの内容を、誰へ、どの条件で再利用してよいかを明示し、複数利用者の試験で維持することが安全な運用の基準になります。
スポンサーリンク
参考資料
以下は2026年10月18日に直接確認した一次資料です。製品やサービスの設定は、実際に利用する版と環境に対応する資料で確認してください。
