Cache Busting DDoSとは？キャッシュをすり抜けてオリジンサーバーを攻撃する仕組みと対策

Cache Busting DDoSとは？キャッシュをすり抜けてオリジンサーバーを疲弊させる攻撃の仕組みと対策

WebサイトやAPIを運営していると、「CDNを入れているからDDoS対策はある程度できている」と考えがちです。
たしかにCDNやキャッシュは、大量アクセスからオリジンサーバーを守る重要な仕組みです。

しかし、攻撃者はそのキャッシュの仕組みを逆手に取ることがあります。
その代表例が Cache Busting DDoS（キャッシュバスティングDDoS） です。

Cache Busting DDoSは、単純に大量の通信を送りつけるだけの攻撃ではありません。
一見すると普通のHTTPリクエストに見えますが、URLやクエリ文字列を毎回変化させることで、CDNやキャッシュを効きにくくし、裏側のオリジンサーバー、アプリケーション、データベースへ負荷を集中させる攻撃です。

この記事では、Cache Busting DDoSの仕組み、通常アクセスとの違い、被害が出やすいポイント、そして実運用で取るべき対策をわかりやすく解説します。

Cache Busting DDoSとは

Cache Busting DDoSとは、攻撃者が毎回異なるURLやクエリ文字列を付けたリクエストを大量に送信し、キャッシュを意図的に効かせにくくするDDoS攻撃です。

通常、Webサイトでは同じ画像、CSS、JavaScript、HTMLページ、APIレスポンスなどをCDNやキャッシュサーバーに保存します。
これにより、同じコンテンツへのアクセスが繰り返された場合、毎回オリジンサーバーへ取りに行かず、CDN側で高速に返せます。

たとえば、次のようなURLが何度もアクセスされる場合です。

/images/banner.webp
/css/style.css
/news/detail/100

このような同一URLへのアクセスであれば、CDNやリバースプロキシのキャッシュが効きやすく、オリジンサーバーへの負荷は抑えられます。

しかしCache Busting DDoSでは、攻撃者がURLの末尾にランダムなクエリ文字列を付けます。

/images/banner.webp?v=1001
/images/banner.webp?v=1002
/images/banner.webp?v=1003

人間から見ると同じ画像へのアクセスに見えても、キャッシュサーバーから見ると「別のURL」と判断される場合があります。
その結果、キャッシュヒットせず、毎回オリジンサーバーへ処理が流れてしまいます。

これがCache Busting DDoSの基本的な考え方です。

なぜキャッシュを回避されると危険なのか

Webサービスでは、CDNやキャッシュによって大量アクセスを吸収しているケースが多くあります。

たとえば、トップページ、画像、CSS、JavaScript、記事ページなどは、キャッシュが効いていれば非常に少ない負荷で配信できます。
CDNが利用者に近い場所からコンテンツを返してくれるため、サイト表示も速くなります。

しかし、キャッシュを回避されると状況が変わります。

本来ならCDNで止まるはずだったリクエストが、すべてオリジンサーバーへ流れます。
オリジン側では、Webサーバー、DjangoやPHPなどのアプリケーション、データベース、ストレージ、外部APIなどが毎回処理を行うことになります。

その結果、次のような問題が発生します。

レスポンスが急に遅くなる
CPUやメモリ使用率が上がる
DB接続数が増える
ディスクI/Oが増える
503エラーやタイムアウトが増える
通常ユーザーのアクセスまで巻き込まれる

つまりCache Busting DDoSは、回線帯域だけを狙う攻撃ではなく、キャッシュの裏側にある本丸のサーバー処理を疲弊させる攻撃 と言えます。

通常アクセスとCache Busting DDoSの違い

通常アクセスでは、同じURLが繰り返し使われます。
そのため、キャッシュが効きやすく、CDNやリバースプロキシでアクセスを吸収できます。

一方、Cache Busting DDoSでは、同じファイルや同じページを狙っているように見えても、URLやクエリ文字列が毎回変化します。

通常アクセスの例です。

GET /banner.webp
GET /banner.webp
GET /banner.webp

Cache Busting DDoSで見られる例です。

GET /banner.webp?x=a8f91
GET /banner.webp?x=k39sd
GET /banner.webp?x=p02aa

このように、パスは同じでもクエリが異なるリクエストが大量に発生します。
その結果、キャッシュサーバーが毎回別物として扱い、オリジンサーバーへの到達数が増えてしまいます。

特に危険なのは、動的ページや検索API、商品一覧、ログイン前でもアクセスできる重いAPIなどです。
これらはキャッシュしづらい場合が多く、攻撃対象になるとアプリケーションやデータベースに直接負荷がかかります。

狙われやすいリソース

Cache Busting DDoSで狙われやすいのは、次のようなリソースです。

まず、画像や動画サムネイルなどの静的ファイルです。
通常はCDNで配信されるため安全に見えますが、クエリ文字列の扱いが甘いとキャッシュミスを誘発されます。

次に、CSSやJavaScriptです。
これらもアクセス数が多く、サイト全体で読み込まれるため、キャッシュが効かなくなると配信負荷が増えます。

さらに注意すべきなのが、APIです。
検索、ランキング、記事一覧、商品一覧、コメント取得、ユーザー情報取得などのAPIは、DBアクセスを伴うことがあります。
ここに大量のランダムクエリを投げられると、アプリケーションサーバーだけでなく、データベースまで負荷が波及します。

特にDjango、Laravel、Rails、WordPressなどのCMSやWebアプリでは、動的処理が多いため、Cache Busting DDoSの影響を受けやすい設計になっていることがあります。

検知で見るべきポイント

Cache Busting DDoSを見つけるには、単純なアクセス数だけでなく、キャッシュやURLの変化を見る必要があります。

重要な監視指標は次の通りです。

キャッシュヒット率が急に低下していないか
オリジンサーバーへの到達数が急増していないか
同じパスに対して異なるクエリ文字列が大量に付いていないか
画像、CSS、JS、APIへのアクセス傾向が急変していないか
5xxエラーやレスポンスタイムが悪化していないか
特定IPだけでなく、広いIP範囲から薄く広く来ていないか
User-Agentが偏っていないか
通常ユーザーでは使わないパラメータが増えていないか

特に重要なのは、同じパスなのにクエリだけが大量に違う という状態です。

たとえば、次のようなアクセスが短時間に大量発生している場合は注意が必要です。

/article/100?cache=xxxx
/article/100?cache=yyyy
/article/100?cache=zzzz

このようなアクセスは、見た目には普通のHTTPリクエストですが、キャッシュ効率を下げる目的で行われている可能性があります。

主な対策

Cache Busting DDoSへの対策は、1つの設定だけで完璧に防ぐというより、複数の防御を組み合わせることが重要です。

1. CDNのキャッシュルールを見直す

まず重要なのは、CDN側でクエリ文字列をどう扱うかです。

すべてのクエリ文字列を別URLとして扱う設定になっていると、不要なキャッシュミスが増えます。
画像、CSS、JavaScriptなど、クエリが表示内容に影響しないリソースでは、クエリ文字列を無視する、または必要なパラメータだけ許可する設計が有効です。

2. クエリ文字列を正規化する

攻撃者がランダムなパラメータを付けても、アプリ側やCDN側で不要なパラメータを落とせば、キャッシュ効率を守れます。

たとえば、許可されたパラメータ以外は無視する、順序を正規化する、意味のないパラメータは削除する、といった対策です。

3. WAFとRate Limitを使う

WAFでは、異常なクエリパターンや高頻度アクセスを検知できます。
また、Rate Limitを使えば、短時間に同じパスへ大量アクセスするクライアントを制限できます。

ただし、正規ユーザーまで巻き込まないように、URL単位、IP単位、User-Agent単位、セッション単位などを組み合わせて慎重に設計する必要があります。

4. Bot対策やChallengeを導入する

明らかに自動化されたアクセスに対しては、Bot対策やChallengeを使うことも有効です。
Cloudflare Turnstileのような仕組みや、WAF側のBotスコアを使うことで、人間の通常アクセスと機械的なアクセスを分けやすくなります。

5. オリジン保護を強化する

CDNを使っていても、オリジンサーバーが直接アクセス可能な状態では危険です。
CDN経由のアクセスだけを許可し、オリジン直叩きを防ぐ構成にすることが重要です。

また、Nginxやアプリ側でも、重いAPIに対してレート制限やキャッシュを設定し、DBへ直接負荷が流れないようにします。

まとめ

Cache Busting DDoSは、キャッシュをすり抜けることで、オリジンサーバーやアプリケーションに負荷を集中させる攻撃です。

一見すると普通のHTTPアクセスに見えるため、単純なDDoS対策だけでは見逃されることがあります。
特に、CDNを導入しているサイトでも、クエリ文字列の扱いやキャッシュルールに不備があると、攻撃の影響を受ける可能性があります。

防御のポイントは、次の3つです。

1つ目は、CDNやキャッシュの設定を正しく設計すること。
2つ目は、同一パスへの多様なクエリやキャッシュヒット率低下を監視すること。
3つ目は、WAF、Rate Limit、Bot対策、オリジン保護を組み合わせることです。

DDoS攻撃は、単に「大量通信を止める」時代から、「アプリやキャッシュの弱点を狙う」時代へ変化しています。
Cache Busting DDoSはその代表的な例です。

Webサイトを安定して運用するためには、CDNを入れるだけで安心せず、キャッシュが本当に効いているか、オリジンに不要な負荷が流れていないかを継続的に確認することが大切です。