HTTPキャッシング：パーソナライズされた応答の保護

このガイドが達成するのに役立つこと

• レイヤーのインベントリ
• 保持期間の選択
• キーの検査
• 再検証と変更の実行

クイックチェック

• キャッシュなしとは、何も保持されないという意味でしょうか？
• Varyはアクセス権限を保護するのか？
• すべてのAPIをキャッシュすべきか？

手順

1. 1

   レイヤーのインベントリ

   ブラウザ、CDN、プロキシ、サービスワーカー、およびアプリケーションのキャッシュを一覧表示する。 パブリックレスポンスとパーソナライズされたレスポンスを分類する。 HTTPポリシーは、コードで実装されたキャッシュを自動的に記述するものではない。

   成果物：レイヤーと所有者の図。

2. 2

   保持期間の選択

   RFC 9111はディレクティブを区別している。no-cacheは再利用前に検証が必要であり、no-storeは関連するHTTPストレージを禁止し、unqualified privateは共有ストレージを除外する。 いずれか一つだけではシステムの機密性を保証することはできません。

   成果物：レスポンスごとの保持ポリシー。

3. 3

   キーの検査

   メソッド、URI、および表現を変更するディメンションをチェックします。 変更はリクエストフィールドに関するものであり、認証ではありません。 アプリケーション層で省略された言語、フォーマットのネゴシエーション、およびアカウントコンテキストを探索します。

   成果物：キーと分離テスト。

4. 4

   再検証と変更の実行

   新規レスポンスと古いレスポンス、データ更新、および取り消された権限をテストします。 ETag、条件付き検証、およびオリジンが利用できない場合の動作を検査します。 以前は正しかったレスポンスも、取り消し後に機密情報となる可能性があります。

   成果物：前後トレース

5. 5

   2つのアカウントを使用したリプレイテスト

   架空のIDとマーカーを使用。 ウォームキャッシュとコールドキャッシュを使用して、同じURIへのリクエストを交互に実行。 ログアウト、直接リンク、および実際のトークンを記録しないログ記録を検証。

   成果物：ネガティブテストと無効化戦略

再利用可能なワークシート

承認された観察結果を記入してください。 これらのフィールドは作業用テンプレートであり、観察結果ではありません。

メカニズムの区別

管理指標

よくある間違い

• ストレージなしとは解釈しない
• 機密性保証とは解釈しない
• アプリケーション キャッシュと履歴を個別にチェックする