AWS WAFのCAPTCHA機能について

AWS WAFのCAPTCHA機能は、WebサイトやWebアプリケーションにアクセスしてきたユーザーに対して、人間による操作かどうかを確認するための機能です。

通常のWAFでは、条件に一致したリクエストを「許可する」「ブロックする」「記録だけする」といった制御が中心です。

一方、CAPTCHAを使うと、怪しいアクセスをすぐにブロックするのではなく、CAPTCHA認証を通過できた場合のみ処理を続ける、という中間的な対策ができます。

たとえば、ログインページへの大量アクセス、問い合わせフォームへのスパム投稿、会員登録フォームへの不正アクセス、検索ページや商品一覧ページへのスクレイピングなどに対して有効です。

AWS WAFのCAPTCHAは、アプリケーション側に大きな改修を加えず、WAFのルールとして設定できる点が特徴です。

CloudFrontやApplication Load Balancer、API Gatewayなどの前段で制御できるため、AWS環境でWebサイトを運用している場合は導入しやすいBot対策のひとつです。

AWS WAFのCAPTCHAでできること

AWS WAFのCAPTCHAでは、特定の条件に一致したリクエストに対してCAPTCHA認証を求めることができます。

たとえば、次のような条件を設定できます。

ログインページへの大量アクセスにCAPTCHAを出す

ログインページは、ブルートフォース攻撃やクレデンシャルスタッフィング攻撃の対象になりやすい場所です。

AWS WAFのCAPTCHAを使えば、短時間に何度もログインページへアクセスしているIPアドレスや、通常とは異なるアクセスパターンを示すリクエストに対してだけCAPTCHAを出すことができます。

すべてのユーザーにCAPTCHAを表示するのではなく、怪しい挙動をしたユーザーだけに表示できるため、正規ユーザーの利便性を大きく損なわずに不正ログイン対策を強化できます。

問い合わせフォームや会員登録フォームのスパムを防ぐ

問い合わせフォーム、資料請求フォーム、コメント投稿欄、会員登録フォームなどは、Botによるスパム投稿の対象になりやすい箇所です。

AWS WAFのCAPTCHAを使うことで、短時間に何度もPOSTリクエストを送ってくるアクセスや、通常では考えにくい頻度でフォーム送信を行うアクセスに対して、人間確認を挟むことができます。

これにより、フォームスパムの削減や、不要なリード情報の混入防止につながります。

スクレイピング対策に使う

商品一覧ページ、検索結果ページ、記事一覧ページ、価格情報ページなどは、スクレイピングの対象になりやすいページです。

AWS WAFのCAPTCHAは、短時間に大量のページを取得するアクセスや、Botらしい挙動を示すアクセスに対してCAPTCHAを表示できます。

ただし、スクレイピング対策では、最初からCAPTCHAを多用すると正規ユーザーの体験に影響する可能性があります。

そのため、まずはChallengeやレート制限を使い、それでも怪しいアクセスに対してCAPTCHAを出すような段階的な設計が望ましいです。

特定の国やIPアドレスに対してCAPTCHAを出す

AWS WAFでは、国や地域、IPアドレス、ヘッダー、User-Agent、URIパスなどを条件にしてルールを作成できます。

そのため、通常のユーザーが少ない国や地域からログインページにアクセスがあった場合だけCAPTCHAを出す、といった設定も可能です。

完全にブロックすると正規ユーザーを巻き込む可能性がある場合でも、CAPTCHAを挟むことで、人間のユーザーには通過手段を残しながらBot対策を行えます。

CAPTCHAとChallengeの違い

AWS WAFには、CAPTCHAと似た機能としてChallengeがあります。

どちらもBot対策に使われますが、ユーザーへの見え方や用途が異なります。

CAPTCHAはユーザーに操作を求める

CAPTCHAは、ユーザーに対してパズルや画像選択などの認証を表示し、人間による操作であることを確認します。

そのため、Botに対しては強い摩擦を与えられますが、正規ユーザーにとっては手間が増えるというデメリットもあります。

ログイン、会員登録、フォーム送信など、不正アクセスやスパムが発生しやすい重要な導線で使うのに向いています。

Challengeは基本的にユーザー操作なしで検証する

Challengeは、ブラウザ上でサイレントに実行される検証です。

通常、ユーザーにパズルを解かせることはありません。

ブラウザがJavaScriptを実行できるか、正しくトークンを取得できるかなどを確認し、Botらしいアクセスをふるい分けます。

CAPTCHAよりもユーザー体験への影響が小さいため、まずChallengeを使い、それでも疑わしいアクセスにCAPTCHAを出すという使い分けが実務では有効です。

使い分けの考え方

CAPTCHAとChallengeは、どちらか一方だけを使うものではありません。

一般的には、次のように使い分けるとバランスが取りやすくなります。

通常のアクセスには何も表示せず、少し怪しいアクセスにはChallengeを実行します。

さらにリスクが高いアクセスや、重要なフォーム送信、ログイン試行などにはCAPTCHAを出します。

明らかに悪意があるアクセスはブロックします。

このように段階的に制御することで、セキュリティとユーザー体験の両立がしやすくなります。

AWS WAF CAPTCHAの仕組み

AWS WAFのCAPTCHAは、リクエストがWAFルールに一致したときに実行されます。

有効なCAPTCHAトークンを持っていないユーザーにはCAPTCHAが表示され、ユーザーが認証を完了するとトークンに成功情報が記録されます。

その後、一定時間は再度CAPTCHAを解かずにアクセスできるようになります。

トークンによって認証状態を管理する

AWS WAFでは、CAPTCHAやChallengeの結果をトークンで管理します。

ユーザーがCAPTCHAを解くと、その成功状態がトークンに記録されます。

次回以降のリクエストでは、AWS WAFがそのトークンを確認し、有効であれば再度CAPTCHAを表示せずにルール評価を続けます。

ただし、CAPTCHAを通過したからといって、そのリクエストが必ず許可されるわけではありません。

CAPTCHAルールを通過した後も、Web ACL内の後続ルールの評価は続きます。

後続のルールでSQLインジェクションやXSSなどに該当すれば、最終的にブロックされる可能性があります。

つまり、CAPTCHA成功は「最終的な許可」ではなく、「そのCAPTCHAルールを通過し、次のルール評価に進む」という意味です。

免除時間を設定できる

AWS WAFのCAPTCHAでは、ユーザーが一度CAPTCHAを通過した後、どのくらいの時間再認証を不要にするかを設定できます。

この時間を短くしすぎると、正規ユーザーに何度もCAPTCHAが表示されてしまいます。

一方で、長くしすぎると、一度通過したBotに長時間の猶予を与えてしまう可能性があります。

実務では、ログインや問い合わせフォームでは数分から十数分程度、管理画面や限定的な用途ではもう少し長めに設定するなど、用途に応じて調整します。

HTMLページではインタースティシャル画面を返せる

通常のHTMLページへのGETリクエストであれば、AWS WAFがCAPTCHA用の画面を返し、ユーザーに認証を求めることができます。

ユーザーがCAPTCHAを解くと、元のリクエストが再送信され、ページへのアクセスが続行されます。

この方式は、ログインページや通常のWebページでは使いやすいです。

一方で、API通信や非同期通信では、そのまま使うとフロントエンド側の処理が崩れる可能性があります。

JavaScript APIによるCAPTCHA表示

AWS WAFには、CAPTCHAをWebアプリケーション内に組み込むためのJavaScript APIがあります。

通常のインタースティシャル方式では、WAFがCAPTCHA画面を返します。

一方、JavaScript APIを使うと、ログインフォームや送信フォームの中など、アプリケーション側で指定した場所にCAPTCHAを表示できます。

SPAやフォーム送信ではJavaScript APIが有効

React、Vue、Next.jsなどを使ったSPAや、fetch・XHRによる非同期通信を行うWebアプリでは、WAFが自動で返すCAPTCHA画面をそのまま扱いにくい場合があります。

このような場合は、JavaScript APIを使って、ユーザーがフォームを送信する前にCAPTCHAを表示し、成功後にAPIリクエストを送信する設計にした方が自然です。

たとえば、ログインボタンを押したタイミングでCAPTCHAを表示し、認証に成功した場合だけログインAPIへリクエストを送る、といった構成が考えられます。

暗号化APIキーが必要になる

JavaScript APIを使う場合は、クライアントドメインに対応した暗号化APIキーが必要です。

これは、CAPTCHAを表示するWebサイトのドメインと関連付けられたキーで、不正なドメインからの利用を防ぐために使われます。

そのため、本番環境だけでなく、ステージング環境や検証環境でも利用する場合は、それぞれのドメインを考慮して設定する必要があります。

CSPの設定に注意する

Content Security Policyを設定しているサイトでは、AWS WAFのCAPTCHA関連スクリプトがブロックされる可能性があります。

CSPを厳しく設定している場合は、AWS WAFのJavaScript APIが正常に読み込まれるように、必要なドメインを許可リストに追加する必要があります。

CAPTCHAを設定したのに表示されない場合や、ブラウザのコンソールにスクリプト読み込みエラーが出ている場合は、CSPの設定を確認するとよいでしょう。

AWS WAF CAPTCHAを利用できる主なサービス

AWS WAFは、複数のAWSサービスと連携して利用できます。

代表的な保護対象は次の通りです。

CloudFront

CloudFrontは、AWS WAFと組み合わせて使われることが多いサービスです。

Webサイト全体の前段にCloudFrontを置き、そのCloudFrontディストリビューションにAWS WAFを関連付けることで、世界中からのアクセスに対してWAFルールを適用できます。

静的サイト、WordPress、ECサイト、メディアサイト、SaaSなど、幅広い用途で利用しやすい構成です。

Application Load Balancer

Application Load BalancerにAWS WAFを関連付けることで、ALB配下のWebアプリケーションを保護できます。

EC2やECS、EKSなどでWebアプリケーションを運用している場合に使いやすい構成です。

API Gateway

API GatewayのREST APIにAWS WAFを関連付けることで、APIに対する不正アクセスや過剰なリクエストを制御できます。

ただし、APIに対してCAPTCHAを直接返す設計は扱いにくい場合があります。

そのため、API保護ではChallengeやレート制限、アプリ側の認証、JavaScript APIとの組み合わせを検討する必要があります。

AppSync、Cognito、App Runner、Amplify、Verified Access

AWS WAFは、AppSync GraphQL API、Amazon Cognitoユーザープール、AWS App Runner、AWS Amplify、AWS Verified Accessなどにも対応しています。

Cognitoのログインやサインアップを保護したい場合、Amplifyで構築したWebアプリを保護したい場合などにも、AWS WAFのCAPTCHAやChallengeを検討できます。

AWS WAF CAPTCHAの料金

AWS WAFのCAPTCHAは、通常のWAF利用料金とは別に追加料金が発生します。

CAPTCHAは、ユーザーがCAPTCHAチャレンジを完了し、その試行がAWS WAFに分析のため送信されたタイミングで課金対象になります。

成功した場合だけでなく、失敗した場合も、分析されたCAPTCHA試行は課金対象になります。

CAPTCHAの対象を広げすぎるとコストが増える

CAPTCHAをサイト全体に適用すると、正規ユーザーにも多く表示されるだけでなく、料金も増えやすくなります。

そのため、CAPTCHAは高リスクなページや条件に限定して使うのが基本です。

たとえば、次のような箇所に絞ると現実的です。

ログインページ、会員登録フォーム、問い合わせフォーム、コメント投稿、購入手続き、検索API、管理画面などです。

Challengeの方が低コストで使いやすい場合がある

Challengeは、CAPTCHAよりもユーザー体験への影響が小さく、料金面でも使いやすいケースがあります。

そのため、すべての怪しいアクセスにCAPTCHAを出すのではなく、まずChallengeでふるい分け、その後さらにリスクが高いアクセスにCAPTCHAを出す構成が有効です。

AWS WAF CAPTCHAのメリット

AWS WAFのCAPTCHAには、セキュリティ面だけでなく、運用面でもメリットがあります。

アプリケーション改修を抑えて導入できる

AWS WAFのCAPTCHAは、WAFのルールとして設定できます。

そのため、Webアプリケーション側にCAPTCHA機能を一から実装しなくても、WAFレイヤーでBot対策を追加できます。

特に、既存のWebサイトやWordPressなどに後から対策を追加したい場合には導入しやすい方法です。

怪しいアクセスをすぐにブロックせずに済む

不正アクセス対策では、誤検知が問題になります。

怪しいアクセスをすべてブロックしてしまうと、正規ユーザーを巻き込む可能性があります。

CAPTCHAを使えば、人間のユーザーには通過手段を残しつつ、Botには高いハードルを与えられます。

AWS WAFの他機能と組み合わせやすい

AWS WAFのCAPTCHAは、レートベースルール、IPレピュテーション、Geo match、マネージドルール、Bot Control、ラベルマッチなどと組み合わせて使えます。

単純にCAPTCHAを表示するだけではなく、複数の条件を組み合わせて、リスクの高いアクセスだけを対象にすることができます。

AWS WAF CAPTCHAの注意点

AWS WAFのCAPTCHAは便利な機能ですが、導入時にはいくつか注意すべき点があります。

ユーザー体験に影響する

CAPTCHAは、ユーザーに追加操作を求める機能です。

そのため、表示頻度が高すぎると、ログイン率、フォーム送信率、購入率、会員登録率などに悪影響が出る可能性があります。

特に、広告流入を受けるランディングページや資料請求フォーム、ECサイトの購入フローでは注意が必要です。

CVRに影響する可能性がある

Webマーケティングの観点では、CAPTCHAの表示はコンバージョン率に影響する可能性があります。

フォーム送信の直前にCAPTCHAが出ると、ユーザーが離脱する原因になることがあります。

特に、入力項目が多いフォームやスマートフォンからのアクセスでは、CAPTCHAが大きな負担になる場合があります。

そのため、全ユーザーにCAPTCHAを出すのではなく、短時間に複数回送信しているユーザーや、Botらしい挙動を示すアクセスに限定して表示するのが望ましいです。

APIやSPAでは設計に注意が必要

APIやSPAでは、WAFが自動で返すCAPTCHAページをそのまま扱うと、アプリケーション側で想定外のレスポンスとして処理される可能性があります。

そのため、API中心の構成では、JavaScript APIやモバイルSDK、Challenge、アプリケーション側の認証・レート制限などを組み合わせて設計する必要があります。

HTTPSが必要

AWS WAFのCAPTCHAやChallengeは、HTTPS環境での利用が前提です。

本番環境では通常HTTPS化されていることが多いですが、検証環境や一部の社内環境ではHTTPのままになっている場合があります。

その場合、CAPTCHAやChallengeが期待どおりに動作しない可能性があります。

CAPTCHAだけでは完全なBot対策にはならない

CAPTCHAは有効なBot対策ですが、万能ではありません。

CAPTCHA解決サービスを利用するBotや、実際のブラウザを操作する自動化Bot、低頻度で分散アクセスするBotには、CAPTCHAだけでは十分でない場合があります。

そのため、AWS WAFのマネージドルール、Bot Control、レート制限、IPレピュテーション、アプリケーション側の認証、ログ監視などと組み合わせて使うことが重要です。

AWS WAF CAPTCHAの導入手順

AWS WAFのCAPTCHAを導入する際は、いきなり本番で強く適用するのではなく、段階的に進めるのが安全です。

まずログを確認する

最初に、どのページにどのような不正アクセスが来ているのかを確認します。

ログインページへの大量アクセスなのか、フォームスパムなのか、スクレイピングなのかによって、設定すべきルールは変わります。

URI、IPアドレス、国、User-Agent、リクエスト頻度、HTTPメソッドなどを確認し、CAPTCHAを適用すべき対象を絞り込みます。

Countモードで影響範囲を見る

本番環境でいきなりCAPTCHAを表示すると、正規ユーザーに影響する可能性があります。

そのため、まずはCountモードでルールを作成し、どれくらいのリクエストが対象になるのかを確認します。

この段階で、正規ユーザーが多く該当している場合は、条件を見直す必要があります。

高リスクなページに限定して適用する

CAPTCHAは、まず高リスクなページに限定して適用するのが基本です。

ログインページ、会員登録、問い合わせフォーム、コメント投稿、検索結果、管理画面など、Botや攻撃者に狙われやすいページから始めるとよいでしょう。

免除時間を調整する

CAPTCHAを導入した後は、免除時間を調整します。

CAPTCHAが頻繁に表示されすぎていないか、逆に一度通過した後の猶予が長すぎないかを確認します。

ユーザー体験とセキュリティのバランスを見ながら、適切な値に調整することが重要です。

ログとメトリクスを継続的に確認する

CAPTCHAを設定した後も、ログやメトリクスを継続的に確認します。

CAPTCHAの発生回数、対象URI、対象IP、国、User-Agent、課金状況、正規ユーザーへの影響などを確認し、必要に応じてルールを調整します。

攻撃パターンは変化するため、一度設定して終わりではなく、定期的な見直しが必要です。

AWS WAF CAPTCHAのおすすめ設定例

AWS WAFのCAPTCHAは、目的に応じて設定方針を変えることが重要です。

ログイン保護

ログインページでは、短時間に一定回数以上アクセスしているIPアドレスや、通常とは異なる挙動を示すアクセスに対してCAPTCHAを表示します。

通常のユーザーには表示せず、不自然なログイン試行に対してだけCAPTCHAを出すことで、ユーザー体験を守りながら不正ログイン対策を強化できます。

フォームスパム対策

問い合わせフォームや会員登録フォームでは、短時間に複数回送信しているアクセスや、特定の条件に該当するPOSTリクエストに対してCAPTCHAを表示します。

フォームスパムを削減しながら、通常のユーザーにはできるだけ余計な操作を求めない設計が理想です。

スクレイピング対策

スクレイピング対策では、ページ閲覧数やリクエスト頻度、Bot Controlの判定、User-Agent、ヘッダー情報などを組み合わせて、疑わしいアクセスにChallengeまたはCAPTCHAを適用します。

いきなりCAPTCHAを広く出すのではなく、Challenge、レート制限、CAPTCHA、Blockを段階的に使い分けるとよいでしょう。

国や地域ごとの制御

通常のユーザーが少ない地域からのログインやフォーム送信に対してCAPTCHAを出す設計も可能です。

ただし、国や地域だけで制御すると、海外在住の正規ユーザーやVPN利用者を巻き込む可能性があります。

そのため、地域条件だけでなく、リクエスト頻度や対象URIなどと組み合わせて判断することが重要です。

Webマーケティング視点での考え方

AWS WAFのCAPTCHAは、セキュリティ対策として有効ですが、マーケティング導線に入れる場合は慎重に設計する必要があります。

全ユーザーにCAPTCHAを出さない

フォームスパムを防ぎたいからといって、すべてのユーザーにCAPTCHAを表示するのはおすすめできません。

特に、広告から流入したユーザーや、スマートフォンでフォーム入力しているユーザーにとって、CAPTCHAは離脱要因になりやすいです。

基本的には、通常のユーザーにはCAPTCHAを表示せず、異常な行動をしたユーザーにだけ表示する設計が望ましいです。

CVRを見ながら調整する

CAPTCHA導入後は、セキュリティ指標だけでなく、コンバージョン率も確認する必要があります。

問い合わせ完了率、会員登録完了率、購入完了率、フォーム離脱率などを見て、CAPTCHAが過剰に表示されていないかを確認します。

もしCVRが低下している場合は、CAPTCHAの対象条件を絞る、Challengeを優先する、免除時間を調整するなどの対策が必要です。

スパム削減と機会損失のバランスを取る

CAPTCHAの目的は、スパムやBotを減らすことです。

しかし、CAPTCHAによって正規ユーザーが離脱してしまうと、機会損失につながります。

そのため、マーケティングサイトでは、セキュリティだけでなく、ユーザー体験と成果への影響を含めて設計することが重要です。

AWS WAF CAPTCHAを使うべきケース

AWS WAFのCAPTCHAは、次のようなケースで特に有効です。

不正ログイン対策を強化したい場合

ログインページへの攻撃が多い場合、CAPTCHAは有効な対策になります。

特に、短時間に大量のログイン試行が発生している場合や、海外からの不自然なアクセスが多い場合に効果を発揮します。

フォームスパムを減らしたい場合

問い合わせフォームや会員登録フォームにスパム投稿が多い場合、CAPTCHAを使うことでBotによる自動送信を抑制できます。

ただし、正規ユーザーへの影響を抑えるため、異常な送信パターンに限定して表示するのがおすすめです。

完全ブロックでは正規ユーザーを巻き込みそうな場合

怪しいアクセスをすぐにブロックすると、正規ユーザーまで遮断してしまう可能性があります。

そのような場合、CAPTCHAを使えば、人間のユーザーには通過手段を残しつつ、Botを抑制できます。

アプリケーション改修を抑えたい場合

アプリケーション側にCAPTCHA機能を実装する工数を抑えたい場合、AWS WAFのCAPTCHAは有力な選択肢です。

WAFレイヤーで制御できるため、既存システムへの影響を抑えながら導入できます。

AWS WAF CAPTCHAを慎重に使うべきケース

一方で、AWS WAFのCAPTCHAを慎重に使った方がよいケースもあります。

購入や申し込みなどCVRが重要な導線

ECサイトの購入フロー、資料請求、無料トライアル申込、会員登録などでは、CAPTCHAが離脱要因になる可能性があります。

このような導線では、全ユーザーにCAPTCHAを出すのではなく、異常な行動をしたユーザーに限定することが重要です。

API中心の構成

APIのみで構成されたサービスでは、CAPTCHAのインタースティシャル画面をそのまま返しても、クライアント側で適切に処理できない場合があります。

API保護では、JavaScript API、モバイルSDK、Challenge、アプリケーション側の認証・レート制限などを組み合わせる必要があります。

正規クローラーや外部連携が多いサイト

検索エンジン、広告クローラー、外部サービスの連携Botなど、正規のBotアクセスが多いサイトでは、CAPTCHAによって必要なアクセスを妨げる可能性があります。

そのため、正規クローラーや許可したいBotについては、別途除外ルールを設けるなどの設計が必要です。

まとめ

AWS WAFのCAPTCHA機能は、Bot、スパム、不正ログイン、スクレイピングなどの対策として有効な機能です。

怪しいアクセスをすぐにブロックするのではなく、CAPTCHAを通過できたユーザーだけ処理を続けることで、正規ユーザーを救済しながら不正アクセスを抑制できます。

ただし、CAPTCHAはユーザーに追加操作を求めるため、使い方を誤るとユーザー体験やコンバージョン率に悪影響を与える可能性があります。

そのため、AWS WAFのCAPTCHAは、サイト全体に広く適用するのではなく、ログインページ、会員登録フォーム、問い合わせフォーム、検索ページ、管理画面など、リスクの高い箇所に限定して使うのが基本です。

また、CAPTCHAだけに頼るのではなく、Challenge、レート制限、AWS Managed Rules、Bot Control、IPレピュテーション、ログ分析、アプリケーション側の認証などと組み合わせることで、より実効性の高いBot対策になります。

導入時は、まずログを確認し、Countモードで影響範囲を検証し、高リスクな条件に限定してCAPTCHAを適用するのが安全です。

導入後も、CAPTCHAの発生回数、ユーザー体験、CVR、料金を見ながら継続的に調整することが重要です。

以上、AWS WAFのCAPTCHA機能についてでした。

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