CDN キャッシュポイズニングとは？Cache Key とリクエスト処理から見る防御のポイント

ウェブサイトに CDN を導入すると、通常はキャッシュによってオリジンへのトラフィックが減り、読み込み時間も短縮されるため、さまざまな地域のユーザーがより速くコンテンツを取得できるようになります。しかし、多言語対応、会員サービス、パーソナライズされた情報を同時に提供するサイトでは、アプリケーションの実際の動作に合わせてキャッシュ設定を調整する必要があります。

同じ URL でも、同じコンテンツとは限りません。本来区別すべきリクエストを CDN が同じものとして扱うと、共有すべきでないレスポンスが顧客に返されるおそれがあります。さらに攻撃者がこうした判断のずれを利用し、改ざんされたレスポンスを共有キャッシュに入り込ませると、CDN キャッシュポイズニング（Cache Poisoning） が発生する可能性があります。

そのため、CDN のキャッシュ効果を評価する際は、速度やヒット率だけでなく、どのコンテンツを共有してよいのか、そして CDN の判断がオリジンと一致しているか も確認する必要があります。

なぜ同じ URL で異なるコンテンツを返す必要があるのか？

越境 EC サイトを例に考えてみましょう。同じ商品ページを開いても、ユーザーの状況によって表示される内容は異なる場合があります。

• 言語の違い：中国と日本のユーザーがそれぞれ異なる言語を選ぶと、ページのテキストもそれに応じて変わります。
• 通貨の切り替え：ユーザーが表示通貨を切り替えると、商品価格やプロモーション情報もあわせて変わります。
• パーソナライズ情報：会員がログインすると、会員限定の割引価格、アカウント情報、カートの状態がページに表示されます。

こうした違いは、URL パス、Query String、Cookie、HTTP Header、あるいはアプリケーションが判断するログイン状態から生じます。

オリジンから見れば、これらは個別に処理すべきリクエストです。しかし CDN が一部の情報だけでキャッシュを区別していると、異なるバージョンがひとつにまとめられてしまう可能性があります。

なお、誤った言語や通貨が表示されたからといって、必ずしも攻撃を受けているとは限りません。単にキャッシュポリシーとビジネスロジックがかみ合っていないだけということもあります。だからこそ、キャッシュ効率を追求する前に、コンテンツの共有範囲を明確にしておく必要があります。

CDN は同じキャッシュを使えるかどうかをどう判断するのか？

CDN は通常、Cache Key（キャッシュキー） によって、リクエストに対応するキャッシュコンテンツを識別します。Cache Key はキャッシュを検索するためのインデックスと考えるとわかりやすいでしょう。具体的な構成はプラットフォームや設定によって異なり、ドメイン、パス、Query String、指定したリクエスト項目などが含まれます。

たとえば、あるサイトが次の URL で異なる通貨を提供しているとします。

オリジンはこのパラメーターに応じて異なるコンテンツを生成しているのに、CDN が currency を無視していると、バージョンが混在してしまう可能性があります。

キャッシュポイズニングは、さらに攻撃者によるレスポンスの操作が関わるものです。たとえば、アプリケーションが外部から渡された Header を信頼し、その内容をもとにページ内のリンクを生成しているにもかかわらず、CDN がその Header の違いを区別していないケースです。改ざんされたページがキャッシュされると、後から訪れた正規の訪問者にも同じコンテンツが返される可能性があります。

対処方法はアプリケーションの要件に応じて決める必要があります。不要な入力の影響を取り除く、キャッシュポリシーでコンテンツを正しく区別する、あるいはそのレスポンスに共有キャッシュを使わせない、といった方法があります。

Cache Key は複雑なほど良いわけではありません。 すべての Cookie やパラメーターを含めると、再利用率の低いキャッシュバージョンが大量に生まれる可能性があります。また、本人確認や認可が関わるコンテンツは、キャッシュ項目を増やしただけで安全とみなすことはできません。

キャッシュ設定で確認すべき情報とは？

設定の前に、アプリケーションのパスごとに「どの情報がレスポンスを変えるのか」を整理し、そのうえで共有と除外のルールを決めることをおすすめします。

オリジンのキャッシュ指示もあわせて確認が必要です。HTTP キャッシュの仕様では、private は共有キャッシュによるレスポンスの保存を制限し、no-store は保存しないことを求め、no-cache は保存を許可するものの再利用の前に検証を必要とします。この 3 つを混同してはいけません。

デプロイ時には、CDN のルールがオリジンの設定を上書きしていないかを確認し、Vary、Cookie、認可付きリクエストが実際にどう処理されるかもテストしましょう。ファイル名が静的リソースのように見えるというだけで、公開共有に適したコンテンツだと判断してはいけません。

キャッシュ設定はどう検証すればよいのか？

受け入れテストでは、パフォーマンスとコンテンツの正確性の両方を確認する必要があります。隔離されたテスト用ドメインや許可された環境で、テストアカウントと合成データを使い、次の 3 つの段階を順に比較することをおすすめします。

1 回のテストで変える条件はひとつに絞ると、違いがどこから生じているのかを切り分けられます。本文だけでなく、ステータスコード、リダイレクト先、キャッシュ制御、プラットフォームが提供するキャッシュステータス情報も比較しましょう。

特に重要なのが、アカウントをまたいだ確認です。アカウント A が操作を終えた後に、アカウント B や未ログインの訪問者が A の個人情報を受け取ってはいけません。一方で、公開されていて共有が許可されたコンテンツは、正しいバージョンが維持されている必要があります。

つまり、HIT はキャッシュが使われたことを示すにすぎず、返されたコンテンツが正しいかどうかは別途確認が必要です。 ブラウザと CDN で結果が異なる場合は、ブラウザのキャッシュも切り分けて調べ、問題の原因を取り違えないようにしましょう。

速度テスト、Response Header、キャッシュヒット率から CDN の実際のパフォーマンスを確認する方法については、『CDN は本当に機能しているか？速度テストからキャッシュヒット率までのトラブルシューティング手順』もあわせてご覧ください。

ポイズニングの発生を確認した場合は、まず影響を受けたキャッシュ動作を制限し、必要な記録を残します。根本原因を修正してから関連するキャッシュを削除し、再テストを行うことで、誤ったコンテンツが再び書き込まれるのを防ぎます。

システム更新後に見直すべき設定とは？

キャッシュポリシーは、アプリケーションの進化に合わせて見直していく必要があります。次のような変更は、すべて確認の対象に含めましょう。

特に、エッジノード、プロキシ、オリジンの間で、エンコーディング、重複したパラメーター、パスの正規化の解釈が異なる場合、当初の設定の前提が成り立たなくなる可能性があります。アプリケーションチームとネットワークチームが同じテストケースを使って結果を確認する必要があります。

ByteShield は CDN キャッシュポリシーの評価をどう支援するのか？

キャッシュポリシーを評価する際は、まず主要な業務パス、想定されるコンテンツの違い、ログインやパーソナライズの要件を共有いただくと、技術チームがアプリケーションの動作を把握しやすくなります。

ByteShield では、キャッシュポリシーの最適化、Response Header の確認、オリジン関連の異常の調査、パフォーマンス分析といった技術サポートをすでに提供しており、キャッシュ設定を評価する土台として活用いただけます。

実際の評価では、要件を整理し、プラットフォームが対応する設定範囲を確認したうえで、双方で受け入れテストのケースを定義します。コンテンツの正確性、アカウントの分離、パフォーマンスをまとめて確認の対象に含めます。

よくある質問

CDN キャッシュポイズニングとは何ですか？

本来区別すべきリクエストを CDN が同じものとして扱うと、攻撃者はその判断のずれを突いて、改ざんされたレスポンスを共有キャッシュに入り込ませることができます。その結果、後から訪れた正規の訪問者にも同じコンテンツが返される可能性があります。これが CDN キャッシュポイズニング（Cache Poisoning）です。

Cache Key は複雑なほど良いのですか？

いいえ。すべての Cookie やパラメーターを含めると、再利用率の低いキャッシュバージョンが大量に生まれる可能性があります。また、本人確認や認可が関わるコンテンツは、キャッシュ項目を増やしただけで安全とみなすことはできません。まずはアプリケーションのパスごとに、どの情報がレスポンスを変えるのかを整理し、そのうえで共有と除外のルールを決めましょう。

HIT と表示されていれば、キャッシュ設定は正しいと言えますか？

必ずしもそうとは限りません。HIT が証明するのはキャッシュが使われたことだけで、返されたコンテンツが正しいかどうかは別途確認が必要です。検証では本文に加えて、ステータスコード、リダイレクト先、キャッシュ制御、プラットフォームが提供するキャッシュステータス情報も比較し、異なるアカウントや未ログインの訪問者がそれぞれ本来のコンテンツを受け取っているかを確認します。

システム更新後、どのような場合にキャッシュ設定を見直すべきですか？

言語や通貨の追加、会員機能やパーソナライズ機能の追加、API のバージョンアップ、Proxy・ロードバランサー・オリジン構成の変更、CDN キャッシュルールの変更を行った際には、キャッシュポリシーが引き続き想定どおりに機能しているかを再確認する必要があります。

多言語対応、会員サービス、パーソナライズされたページ、高トラフィックの API を運用している場合は、ByteShield のSCDN サービスをご覧いただくか、ByteShield にお問い合わせください。現在のアプリケーション構成と配信要件に応じて、最適な CDN キャッシュとセキュリティのポリシーを一緒に検討します。