AWS WAFのチャレンジとは

AWS WAFのチャレンジ（Challenge）とは、Webサイトやアプリケーションにアクセスしてきたクライアントが、通常のブラウザとして適切に動作できるかを確認するための仕組みです。

簡単にいうと、AWS WAFがアクセス元に対してJavaScriptベースのサイレントな検証を行い、正しく通過できたクライアントにAWS WAFトークンを付与します。

その後のリクエストでは、このトークンを使って「このクライアントはチャレンジを通過済みかどうか」を判定します。

CAPTCHAのように、ユーザーに画像選択やパズル操作を求めるものではありません。

基本的にはユーザーに見えにくい形で処理されるため、正規ユーザーの体験を大きく損なわずに、単純なボットや自動化されたアクセスをふるいにかけることができます。

AWS WAFのチャレンジが使われる目的

AWS WAFのチャレンジは、主にボット対策や不審なアクセスの抑制に使われます。

たとえば、単純なスクレイピングツールやHTTPクライアントは、JavaScriptの実行やトークン管理を正しく行えないことがあります。

そのようなアクセスにチャレンジを出すことで、正規ブラウザからのアクセスは通しつつ、機械的なアクセスを止めたり、攻撃者側の運用コストを高めたりできます。

特に、次のような場面で有効です。

• ログインページへの不審な連続アクセス
• 会員登録フォームへの自動送信
• 商品ページや検索結果ページのスクレイピング
• 価格情報・在庫情報の大量取得
• 低レートで分散して行われるボットアクセス
• L7 DDoS攻撃の一部
• 不審なAPIアクセスの抑制

ただし、チャレンジは万能なボット対策ではありません。

高度なボットはヘッドレスブラウザや実ブラウザ環境を使って、JavaScriptを実行できる場合があります。

そのため、AWS WAFのチャレンジは単体で使うよりも、Rate-based rule、AWS Managed Rules、Bot Control、IPレピュテーション、アプリケーション側のレート制限などと組み合わせて使うのが現実的です。

AWS WAFのチャレンジの仕組み

AWS WAFのチャレンジは、リクエストに有効なAWS WAFトークンがあるかどうかによって挙動が変わります。

有効なトークンがある場合、AWS WAFはそのリクエストをチャレンジ通過済みと判断し、後続のルール評価へ進めます。

一方で、有効なトークンがない場合や、トークンが無効または期限切れの場合は、AWS WAFがチャレンジレスポンスを返し、リクエストを本来の宛先へは送信しません。

有効なトークンがある場合

リクエストに有効なチャレンジトークンが含まれている場合、AWS WAFはそのルールをCountに近い形で扱います。

つまり、チャレンジルールに一致したとしても、すでにチャレンジを通過していると判断されれば、そこでリクエストを止めるのではなく、Web ACL内の後続ルール評価へ進みます。

このとき、必要に応じてラベル付与やカスタムリクエスト処理が行われます。

有効なトークンがない場合

リクエストに有効なトークンがない場合、AWS WAFはWeb ACLの評価を中断し、チャレンジレスポンスを返します。

このとき、リクエストはCloudFront、ALB、API Gatewayなどの背後にあるオリジンへは到達しません。

AWS WAF側で一度止められ、クライアントがチャレンジを通過できるか確認されます。

チャレンジレスポンスには、通常以下のような情報が含まれます。

• HTTPステータス 202 Request Accepted
• x-amzn-waf-action: challenge ヘッダー
• 条件を満たす場合、JavaScriptチャレンジを含むHTMLページ

リクエストの Accept ヘッダーに text/html が含まれている場合は、ブラウザで処理できるJavaScriptチャレンジページが返されます。

チャレンジ通過後の流れ

ブラウザがAWS WAFから返されたチャレンジ用のJavaScriptを実行し、検証に成功すると、AWS WAFトークンが発行または更新されます。

その後、更新されたトークンを使って元のリクエストが再送されます。

AWS WAFは再送されたリクエストに含まれるトークンを確認し、有効であれば後続のルール評価へ進めます。

一般的なHTMLページへのアクセスであれば、この流れはユーザーにほとんど意識されずに実行されます。

通常のブラウザアクセスでの流れ

通常のブラウザアクセスでは、次のような流れになります。

1. ユーザーがWebページにアクセスする
2. リクエストがAWS WAFで評価される
3. チャレンジ対象のルールに一致する
4. 有効なトークンがない場合、AWS WAFがチャレンジレスポンスを返す
5. ブラウザがJavaScriptチャレンジを実行する
6. チャレンジに成功するとAWS WAFトークンが発行・更新される
7. 元のリクエストがトークン付きで再送される
8. 有効なトークンが確認されれば、後続ルール評価へ進む
9. 問題がなければオリジンへリクエストが到達する

このように、チャレンジは単純なAllowやBlockとは異なり、アクセス元に一度検証を求めたうえで通すかどうかを判断する仕組みです。

チャレンジとCAPTCHAの違い

AWS WAFには、チャレンジのほかにCAPTCHAというアクションもあります。

どちらもボット対策に使われますが、ユーザー体験や用途が異なります。

チャレンジは、基本的にユーザー操作を求めないサイレントな検証です。

一方、CAPTCHAはユーザーにパズルや画像選択などの操作を求め、人間であることを確認する仕組みです。

チャレンジとCAPTCHAの比較

項目	チャレンジ	CAPTCHA
ユーザー操作	基本的に不要	必要
検証方法	JavaScriptによるサイレント検証	パズル・画像選択など
ユーザー体験への影響	小さい	大きい
主な目的	ブラウザらしい挙動か確認する	人間であることを確認する
向いている場面	広めのボット対策、低摩擦な防御	より疑わしい操作、重要なフォーム保護
代表的な対象	検索、一覧、ログイン前ページなど	ログイン、登録、投稿、決済前など

実務的には、チャレンジは「ユーザー体験への影響を抑えながら不審なアクセスをふるいにかける対策」、CAPTCHAは「より強く人間確認を行いたい場面で使う対策」と考えると分かりやすいです。

CAPTCHAでもチャレンジが使われることがある

なお、AWS WAFのCAPTCHAでは、実装上、最初にチャレンジスクリプトが実行される場合があります。

そのため、厳密には次のように理解するとよいでしょう。

• チャレンジ：サイレントなブラウザ検証
• CAPTCHA：サイレントなブラウザ検証に加えて、ユーザー向けパズルを行う仕組み

CAPTCHAはチャレンジよりも強い確認手段ですが、その分ユーザーの手間が増えます。

そのため、いきなりCAPTCHAを広範囲に適用するのではなく、まずはチャレンジで低摩擦に判定し、より疑わしい操作にはCAPTCHAを使う設計が現実的です。

チャレンジはブロックではないのか

AWS WAFのチャレンジは、単純なブロックとは異なります。

ただし、「まったくブロックしない」という意味でもありません。

チャレンジは、リクエストに有効なトークンがあるかどうかによって挙動が変わる条件付きのアクションです。

有効なトークンがあれば非終端アクションになる

有効なチャレンジトークンがある場合、そのリクエストはチャレンジ通過済みとして扱われます。

この場合、AWS WAFはリクエストを止めず、後続のルール評価へ進めます。

つまり、この状態ではチャレンジはBlockではなく、Countに近い非終端アクションとして動きます。

有効なトークンがなければ終端的に止める

一方、有効なトークンがない場合、AWS WAFはチャレンジレスポンスを返し、リクエストを本来の宛先へは送りません。

この意味では、未通過のリクエストに対しては終端的に働きます。

そのため、正確には次のように説明できます。

AWS WAFのチャレンジは、有効なトークンがあれば後続評価へ進む非終端アクションとして動作し、有効なトークンがなければチャレンジレスポンスを返してリクエストを一度止める条件付きアクションです。

Immunity timeとは

AWS WAFのチャレンジには、immunity timeという考え方があります。

immunity timeとは、クライアントがチャレンジを通過した後、どれくらいの間「再チャレンジ不要」とみなすかを決める時間です。

たとえば、immunity timeが300秒に設定されている場合、チャレンジ成功後の約5分間は、同じクライアントセッションが有効なトークンを持っていれば、再度チャレンジを求められにくくなります。

immunity timeを短くした場合

immunity timeを短くすると、チャレンジの再実行頻度が高くなります。

これはセキュリティ面では厳しくできますが、正規ユーザーに対してもチャレンジが発生しやすくなるため、ユーザー体験に影響する可能性があります。

また、チャレンジレスポンスが増えれば、追加料金にも影響します。

immunity timeを長くした場合

immunity timeを長くすると、一度チャレンジを通過したクライアントは、長時間再チャレンジを求められにくくなります。

ユーザー体験は良くなりますが、一度チャレンジを通過したボットにも長く猶予を与える可能性があります。

そのため、immunity timeは、セキュリティとユーザー体験のバランスを見ながら設定する必要があります。

APIやSPAでチャレンジを使う際の注意点

AWS WAFのチャレンジは、通常のHTMLページへのブラウザアクセスでは比較的自然に動作します。

しかし、APIリクエスト、SPAのfetch通信、XHR、モバイルアプリからの通信では注意が必要です。

API通信では202レスポンスが問題になることがある

チャレンジ対象になったリクエストに有効なトークンがない場合、AWS WAFはHTTP 202 Request Accepted のチャレンジレスポンスを返します。

通常のHTMLページであれば、ブラウザがチャレンジ用JavaScriptを処理し、トークンを取得して元のリクエストを再送できます。

しかし、API通信では、クライアント側がHTMLのチャレンジページを期待していません。

たとえば、次のような通信では問題が起きる可能性があります。

• fetch('/api/login')
• axios.post('/api/cart')
• モバイルアプリからのAPIリクエスト
• サーバーサイドのHTTPクライアント
• 外部システムからのWebhook
• JSONレスポンスを前提とした通信

これらの通信で突然 202 やHTMLが返ると、アプリケーション側ではエラーとして扱われる可能性があります。

SPAではJavaScript SDKの利用を検討する

React、Vue、Next.jsなどのSPAでAWS WAFのチャレンジを使う場合は、AWS WAFのJavaScript統合を検討する必要があります。

SDKを利用すると、保護対象のAPIへアクセスする前にAWS WAFトークンを取得し、リクエストに含めることができます。

これにより、APIリクエストが突然チャレンジレスポンスで中断されるリスクを減らせます。

モバイルアプリでは専用SDKの利用を検討する

モバイルアプリからAPIを呼び出している場合も同様です。

ブラウザとは異なり、モバイルアプリはAWS WAFのHTMLインタースティシャルを自然に処理できません。

そのため、AndroidやiOS向けの統合を使い、アプリ側でAWS WAFトークンを適切に扱う設計が必要になります。

チャレンジの料金

AWS WAFのチャレンジは、標準的なAllow、Block、Countとは異なり、追加料金の対象です。

重要なのは、チャレンジの課金は「ユーザーが実際にチャレンジを解いたかどうか」ではなく、AWS WAFがチャレンジページを提供した時点で発生するという点です。

無条件に適用するとコストが増えやすい

すべてのリクエストに対して無条件にチャレンジを出すと、正規ユーザーにも大量にチャレンジレスポンスが返される可能性があります。

その結果、ユーザー体験が悪化するだけでなく、AWS WAFの利用料金も増えやすくなります。

チャレンジは便利な機能ですが、広範囲に雑に適用するのではなく、対象パスや条件を絞って使うことが重要です。

チャレンジを適用しやすいページ

AWS WAFのチャレンジは、すべてのページに一律で適用するよりも、ボット被害が発生しやすいページや、攻撃対象になりやすい機能に絞って適用するのが基本です。

ログインページ

ログインページは、credential stuffingやブルートフォース攻撃の対象になりやすい場所です。

短時間に大量のログイン試行がある場合や、疑わしいIP・User-Agentからのアクセスがある場合にチャレンジを出すことで、自動化されたログイン攻撃のコストを高められます。

ただし、ログイン処理がAPI経由で実行されている場合は、チャレンジレスポンスによってログインAPIが失敗しないよう注意が必要です。

会員登録ページ

会員登録フォームは、スパムアカウント作成や不正登録の対象になりやすいページです。

登録ページへのアクセスや登録APIへのリクエストに対してチャレンジを適用することで、単純な自動登録ボットを減らせる可能性があります。

ただし、フォーム送信直前にチャレンジが発生するとユーザー体験に影響するため、フォーム表示時や登録フローの前段でトークンを取得する設計も検討すべきです。

検索結果ページ

検索結果ページは、スクレイピング対象になりやすいページです。

求人サイト、不動産サイト、ECサイト、旅行予約サイト、比較サイトなどでは、検索結果ページに対して大量アクセスが発生することがあります。

このようなページでは、一定以上のアクセス頻度や疑わしい挙動を条件にチャレンジを出すことで、正規ユーザーへの影響を抑えながらスクレイピング対策ができます。

商品ページ・在庫ページ

ECサイトでは、商品価格、在庫情報、レビュー情報などがスクレイピング対象になりやすいです。

特定の商品ページに対して異常な頻度でアクセスしているクライアントや、短時間に多くの商品ページを巡回しているクライアントに対してチャレンジを出すと、単純な収集ボットを抑制しやすくなります。

パスワードリセットページ

パスワードリセットページは、アカウント探索や不正操作の入り口になることがあります。

大量のパスワードリセット要求が発生している場合、チャレンジを使うことで自動化された攻撃のハードルを上げられます。

投稿フォーム・問い合わせフォーム

問い合わせフォームやコメント投稿フォームは、スパム投稿の対象になりやすい場所です。

CAPTCHAを導入するとユーザー体験が悪化する場合でも、まずチャレンジを適用することで、ユーザー操作を増やさずに一定のボット対策ができます。

チャレンジ導入時のベストプラクティス

AWS WAFのチャレンジを導入する際は、いきなり本番環境で広範囲に適用するのではなく、段階的に設定することが重要です。

まずはCountで影響範囲を確認する

最初からChallengeアクションを設定すると、正規ユーザーやAPI通信に影響が出る可能性があります。

まずはCountモードでルールに一致するリクエスト数や対象パス、アクセス元の傾向を確認しましょう。

CloudWatchメトリクスやAWS WAFログを確認し、どの程度のリクエストが対象になるのかを把握してから、チャレンジの適用範囲を決めるのが安全です。

対象パスを絞る

チャレンジは、サイト全体に一律で適用するよりも、リスクの高いパスに限定して使うべきです。

たとえば、以下のようなパスに絞ると実務的です。

• /login
• /signup
• /register
• /password-reset
• /search
• /products
• /cart
• /checkout
• /contact

ただし、これらのパスがAPI通信で使われている場合は、フロントエンドやモバイルアプリとの相性を必ず確認する必要があります。

レートベースルールと組み合わせる

すべてのアクセスにチャレンジを出すのではなく、一定以上のアクセス頻度を超えたクライアントに対してチャレンジを出す方法が有効です。

たとえば、短時間に大量の検索リクエストを送っているIPや、ログインページへ異常に多くアクセスしているIPに対してチャレンジを出すことで、正規ユーザーへの影響を抑えつつボット対策ができます。

Bot Controlと組み合わせる

AWS WAF Bot Controlを利用している場合は、Bot Controlの判定結果に応じてチャレンジを出す設計も有効です。

明らかに悪質なBotはBlockし、疑わしいが誤検知の可能性があるアクセスにはChallengeを出す、といった段階的な制御ができます。

Managed RulesのBlockをChallengeに変更する

AWS Managed Rulesで特定のリクエストがBlockされている場合、誤検知が気になるケースがあります。

そのような場合、一部のルールアクションをBlockではなくChallengeに変更することで、正規ユーザーを完全に遮断せずに検証を挟むことができます。

ただし、攻撃リクエストを通してしまう可能性もあるため、対象ルールの意味やログを確認したうえで慎重に設定する必要があります。

チャレンジ導入時に確認すべきポイント

AWS WAFのチャレンジを導入した後は、必ず動作確認とログ確認を行う必要があります。

HTMLページが正常に表示されるか

まず、通常のブラウザアクセスでチャレンジが自然に処理されるか確認します。

ユーザーがページ遷移したときに、不自然な画面遷移や読み込み失敗が発生していないかを確認しましょう。

API通信が失敗していないか

API、fetch、XHR、モバイルアプリ通信では、チャレンジレスポンスが原因でエラーになることがあります。

チャレンジ導入後に、以下のような問題が起きていないか確認しましょう。

• ログインできない
• カートに商品を追加できない
• 検索結果が取得できない
• フォーム送信が失敗する
• モバイルアプリで通信エラーが増える
• 外部サービス連携やWebhookが失敗する

正規ユーザーへの影響を確認する

チャレンジはサイレントに動作するとはいえ、ネットワーク環境やブラウザ設定によってはうまく処理できない場合があります。

特に、JavaScriptが無効化されている環境や、Cookie制限が強い環境では注意が必要です。

SEOクローラーへの影響を確認する

検索エンジンのクローラーに対して不要なチャレンジを出すと、クロールやインデックスに影響する可能性があります。

SEOが重要なサイトでは、Googlebotなどの正規クローラーをどう扱うかも慎重に検討する必要があります。

ただし、User-Agentだけで安易に許可すると偽装される可能性があるため、AWS WAFのBot Controlや検証済みBotの扱いを踏まえて設計することが重要です。

料金への影響を確認する

チャレンジレスポンスは追加料金の対象です。

導入後は、チャレンジがどの程度発生しているかを確認し、想定以上に課金が増えていないかを監視しましょう。

特に、攻撃時や大量スクレイピング時にはチャレンジレスポンス数が急増する可能性があります。

AWS WAFのチャレンジを使うべきケース

AWS WAFのチャレンジは、次のようなケースに向いています。

正規ユーザーをなるべくブロックしたくない場合

不審なアクセスをすぐにBlockすると、誤検知によって正規ユーザーまで遮断してしまう可能性があります。

チャレンジを使えば、疑わしいリクエストに対して一度検証を挟み、通過できるクライアントは後続処理へ進めることができます。

CAPTCHAほど強い摩擦をかけたくない場合

CAPTCHAは強い確認手段ですが、ユーザーに操作を求めるため、離脱率が上がる可能性があります。

チャレンジであれば、基本的にユーザー操作なしで検証できるため、ユーザー体験への影響を抑えやすいです。

単純なスクレイピングを抑制したい場合

JavaScriptを実行しない単純なスクレイピングツールやHTTPクライアントに対しては、チャレンジが有効に働く場合があります。

特に、検索結果や商品一覧など、機械的に取得されやすいページに適しています。

攻撃者側のコストを上げたい場合

チャレンジを導入すると、攻撃者はJavaScript実行、トークン管理、Cookie処理、セッション維持などに対応する必要があります。

これにより、単純なスクリプトでは攻撃を継続しにくくなり、攻撃者側のコストを引き上げられます。

AWS WAFのチャレンジを使う際の注意点

AWS WAFのチャレンジは便利ですが、設計を誤ると正規ユーザーやアプリケーションに影響を与える可能性があります。

すべてのリクエストに適用しない

チャレンジをサイト全体に一律で適用すると、不要なチャレンジレスポンスが増え、ユーザー体験やコストに悪影響が出る可能性があります。

リスクの高いパスや、一定条件に一致したリクエストに限定して適用するのが基本です。

APIエンドポイントには慎重に適用する

APIエンドポイントに対してチャレンジを適用する場合は、クライアント側がAWS WAFトークンを適切に取得・送信できる設計になっているか確認する必要があります。

SDK統合なしでAPIにチャレンジをかけると、通信エラーの原因になることがあります。

重要な処理の直前だけに出さない

購入完了、フォーム送信、ログイン送信など、ユーザーが操作を完了しようとしているタイミングでチャレンジが発生すると、体験が悪くなる可能性があります。

できれば、その前段階でトークンを取得しておき、重要な処理ではスムーズに通過できるように設計するとよいでしょう。

高度なボットには突破される可能性がある

チャレンジは、JavaScriptを実行できない単純なボットには有効ですが、高度なボットには突破される可能性があります。

そのため、チャレンジだけで完全に守れると考えるのではなく、複数の対策を組み合わせることが重要です。

まとめ

AWS WAFのチャレンジとは、アクセスしてきたクライアントが通常のブラウザとして適切に動作できるかを、JavaScriptベースでサイレントに検証する仕組みです。

有効なAWS WAFトークンがある場合は、チャレンジ通過済みとして後続ルール評価へ進みます。

一方、有効なトークンがない、無効、または期限切れの場合は、AWS WAFがチャレンジレスポンスを返し、リクエストを本来の宛先へ送らずに一度止めます。

CAPTCHAと比べると、チャレンジはユーザー操作を基本的に求めないため、ユーザー体験への影響を抑えながらボット対策を行いやすい点がメリットです。

ただし、API、SPA、モバイルアプリではチャレンジレスポンスをそのまま処理できない場合があるため、JavaScript SDKやモバイルSDKの利用を検討する必要があります。

また、チャレンジレスポンスは追加料金の対象になるため、すべてのリクエストに無条件で適用するのではなく、ログイン、検索、登録、商品一覧、問い合わせフォームなど、リスクの高い箇所に絞って使うことが重要です。

AWS WAFのチャレンジは、正規ユーザーをなるべく妨げずに、単純なボットや不審なアクセスを抑制したい場合に有効な機能です。

導入する際は、Countモードで影響範囲を確認し、対象パスや条件を絞り、ログやメトリクスを見ながら段階的に適用するのが安全です。

以上、AWS WAFのチャレンジについてでした。

最後までお読みいただき、ありがとうございました。