AWS WAFが原因で403エラーが出る場合の対処法について

AWS WAFが原因で403エラーが発生している場合、まず重要なのは「403エラーをすぐに消すこと」ではありません。

大切なのは、どのWAFルールが、どのリクエストに対して、なぜBlock判定をしたのかを特定することです。

AWS WAFは、不正アクセス、SQLインジェクション、クロスサイトスクリプティング、Botアクセス、大量リクエストなどからWebアプリケーションを守るためのサービスです。

そのため、何らかのルールに一致したリクエストは、AWS WAFによってブロックされ、結果として403 Forbiddenが返されることがあります。

ただし、403エラーはAWS WAF以外が原因で発生することもあります。

CloudFront、ALB、API Gateway、S3、アプリケーション側の認証・認可処理などでも403は発生します。

そのため、まずは本当にAWS WAFが原因なのかを確認し、そのうえでブロックしたルールを特定することが大切です。

AWS WAFによる403エラーとは

AWS WAFでBlockされると403が返る

AWS WAFでは、ルールに一致したリクエストに対してBlockアクションが適用されると、通常はHTTP 403 Forbiddenが返されます。

ただし、AWS WAFではBlock時のレスポンスをカスタマイズできます。

そのため、設定によっては403以外のステータスコードや、独自のエラーメッセージが返される場合もあります。

そのため、「403が出ているからAWS WAFが原因」と即断するのではなく、ログやレスポンス内容を確認して判断する必要があります。

403エラーはAWS WAF以外でも発生する

403エラーは、アクセスが拒否されたことを示すHTTPステータスコードです。

AWS環境では、以下のような原因でも403が発生します。

発生元	主な原因
AWS WAF	ルールに一致してBlockされた
CloudFront	地理制限、署名付きURL、オリジン設定の不備
ALB	認証設定、ターゲット側の403レスポンス
API Gateway	IAM認証、リソースポリシー、Authorizer設定
S3	バケットポリシー、ACL、Block Public Access
アプリケーション	ログイン制御、権限不足、CSRFエラー

CloudFront経由でAWS WAFを利用している場合、ユーザーから見るとCloudFrontの403に見えることがあります。

そのため、CloudFrontログだけでなく、AWS WAFログも確認することが重要です。

まず確認すべきこと

本当にAWS WAFが原因か確認する

AWS WAFが原因かどうかを判断するには、次の情報を確認します。

確認項目	内容
発生日時	いつ403が発生したか
対象URL	どのページやAPIで発生したか
HTTPメソッド	GET、POST、PUTなど
クライアントIP	アクセス元のグローバルIP
User-Agent	ブラウザ、bot、監視ツールなど
発生条件	全ユーザーか、特定ユーザーのみか
再現性	毎回発生するか、特定操作のみか
直近の変更	WAF設定、CloudFront設定、アプリ改修など

特に重要なのは、発生日時、URL、IPアドレスです。

この3つが分かると、AWS WAFログから該当リクエストを探しやすくなります。

WAFログまたはSampled requestsを確認する

AWS WAFによる403かどうかを確認するには、AWS WAFのログを確認します。

簡易的な確認であれば、AWS WAFコンソールのSampled requestsを使えます。

Sampled requestsでは、AWS WAFが検査したリクエストのサンプルを確認できます。

ただし、Sampled requestsは全件ログではありません。

特定ユーザーの403、広告配信中の大量アクセス、短時間だけ発生したエラーなどを正確に調べる場合は、AWS WAF loggingを有効化し、CloudWatch Logs、S3、Kinesis Data Firehoseなどに出力して確認するのが安全です。

Sampled requestsに出ていないからといって、AWS WAFが原因ではないとは断定できません。

AWS WAFログで確認すべき項目

action

まず確認すべき項目は、actionです。

action がBlockになっていれば、AWS WAFがそのリクエストをブロックしたことを示します。

ただし、AWS WAFにはAllow、Block、Count、CAPTCHA、Challengeなど複数のアクションがあります。

そのため、Blockだけでなく、CAPTCHAやChallengeによって実質的にリクエストが通らなかったケースも確認する必要があります。

terminatingRuleId

AWS WAFの403調査で最も重要なのが、terminatingRuleIdです。

これは、リクエストの評価を終了させたルールを示します。

つまり、どのルールが最終的にリクエストを止めたのかを確認するための項目です。

たとえば、AWS Managed Rules、Rate-based rule、IP制限ルール、Geo Matchルール、Bot Controlなど、どのルールが原因になったのかを判断する手がかりになります。

terminatingRuleType

terminatingRuleType では、ブロックしたルールの種類を確認できます。

通常のルールなのか、マネージドルールグループなのか、レートベースルールなのかを見分ける際に役立ちます。

ruleGroupList

AWS Managed Rulesなどのマネージドルールグループを利用している場合、terminatingRuleId だけでは個別のルール名が分かりにくいことがあります。

その場合は、ruleGroupList を確認します。

ここを見ることで、ルールグループ内のどの個別ルールに一致したのかを確認できる場合があります。

labels

AWS WAFでは、ルールに一致したリクエストにラベルが付与されることがあります。

特にAWS Managed RulesやBot Controlを使っている場合、ラベルを見ることで、どのようなカテゴリの検知が行われたのかを把握しやすくなります。

terminatingRuleMatchDetails

SQLインジェクションやクロスサイトスクリプティングなど、一部の検知では、terminatingRuleMatchDetails に詳細情報が出る場合があります。

どのリクエスト要素が疑わしいと判断されたのかを確認する際に役立ちます。

AWS WAFによる403エラーのよくある原因

AWS Managed Rulesの誤検知

AWS WAFによる403でよくあるのが、AWS Managed Rulesの誤検知です。

AWS Managed Rulesは、AWSが管理するセキュリティルール群です。

SQLインジェクション、クロスサイトスクリプティング、既知の悪性入力、不審なBot、匿名IPなどを検知できます。

一方で、正常なリクエストが攻撃パターンに似ている場合、誤ってブロックされることがあります。

たとえば、検索フォームにSQL風の文字列が入力された場合、SQLインジェクションと判断されることがあります。

また、CMSの投稿画面でHTMLやJavaScript風の文字列を送信した場合、クロスサイトスクリプティングと判断されることがあります。

SQLインジェクション系ルールによるブロック

検索キーワード、問い合わせ本文、管理画面の入力内容などに、SQL文に似た文字列が含まれていると、SQLインジェクション系ルールに引っかかることがあります。

たとえば、商品検索、サイト内検索、自由入力フォーム、APIのJSONリクエストなどで発生しやすいです。

この場合、アプリケーション側でSQLインジェクション対策が正しく行われているかを確認したうえで、必要に応じて該当ルールや該当パスだけを調整します。

XSS系ルールによるブロック

問い合わせフォーム、CMS投稿画面、LP編集画面、HTMLメール作成画面などでは、HTMLタグやJavaScript風の文字列を送信することがあります。

このようなリクエストが、クロスサイトスクリプティングの攻撃パターンと判断され、403になることがあります。

特に、管理画面や投稿画面では、正常な操作でもHTMLを扱う場合があります。

そのため、一般公開フォームと管理画面を同じWAF条件で扱うと、誤検知が起きやすくなります。

SizeRestrictionsによるブロック

AWS Managed Rulesの中には、リクエストのサイズに関するルールがあります。

たとえば、Body、Cookie、ヘッダー、クエリ文字列などが大きすぎる場合、SizeRestrictions系のルールに一致することがあります。

マーケティングタグ、解析ツール、A/Bテストツール、ヒートマップツールなどを多く導入しているサイトでは、Cookieが肥大化することがあります。

その結果、WAFのサイズ制限系ルールに引っかかる場合があります。

Body検査サイズの上限による影響

AWS WAFが検査できるリクエストBodyサイズには上限があります。

ALBやAppSyncでは8KB固定です。

CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Accessでは、デフォルト16KBで、最大64KBまで拡張できます。

Bodyが上限を超える場合、AWS WAFはリクエスト全体を無制限に検査するわけではありません。

上限内の内容と、Oversize handlingの設定によって挙動が変わります。

そのため、ファイルアップロードで403が出る場合も、ファイル全体が検査されているとは限りません。

multipart/form-dataの先頭部分、ヘッダー、Cookie、URI、クエリ文字列、Body上限内の内容、またはOversize handlingの設定が影響している可能性があります。

IP制限によるブロック

AWS WAFでIP setを使っている場合、特定のIPアドレスがブロック対象になっている可能性があります。

また、社内ネットワーク、VPN、プロキシ、クラウド環境、監視ツールなどからのアクセスが、意図せずブロック対象になることもあります。

この場合は、WAFログでAWS WAFが認識しているクライアントIPを確認します。

CloudFrontやALBを経由している構成では、実際のユーザーIPがどのようにWAFに渡っているかも確認が必要です。

Geo Matchによるブロック

Geo Matchを使って国単位でアクセス制限している場合、特定の国からのアクセスが403になることがあります。

海外からのアクセスを制限しているサイトでは、広告審査、海外拠点、外部監視ツール、海外の検索エンジンクローラーなどが影響を受ける場合があります。

WAFログでは、クライアントIPだけでなく国情報も確認します。

Rate-based ruleによるブロック

Rate-based ruleは、一定時間内に多くのリクエストが発生した場合に制限をかけるルールです。

デフォルトではIPアドレス単位で集約されますが、設定によってはForwarded IP、HTTPメソッド、ヘッダー、Cookie、クエリ引数、複数キーの組み合わせなどでも集約できます。

そのため、「同じIPから大量アクセスがあった」場合だけでなく、「同じAPIキー」「同じUser-Agent」「同じパス」「同じヘッダー値」などで制限されている可能性もあります。

広告配信直後、キャンペーン実施中、SNSで拡散されたタイミングなどは、正常アクセスでも一時的にリクエスト数が増えるため注意が必要です。

Bot Controlによるブロック

AWS WAF Bot Controlを利用している場合、Botと判断されたアクセスが403になることがあります。

Bot Controlは悪性Botの検知に有効ですが、正常なクローラー、広告審査bot、監視ツール、自動テスト、外部連携などが影響を受ける場合もあります。

特に、通常のブラウザユーザーとは異なる挙動をするアクセスは、Bot対策ルールに引っかかる可能性があります。

広告LPやフォームでBot Controlを使っている場合は、広告審査、クローラビリティ、計測タグ、外形監視に影響が出ていないか確認することが重要です。

CAPTCHAやChallengeによる影響

AWS WAFでは、CAPTCHAやChallengeを使って、人間によるアクセスかどうかを判定できます。

ただし、CAPTCHAやChallengeは、ブラウザでのアクセスを前提とする場面に向いています。

API、Webhook、監視ツール、外部システム連携などに適用すると、正常なリクエストが通らなくなる可能性があります。

CAPTCHAやChallengeは、有効なトークンがある場合は後続ルールの評価を続けます。

一方、トークンがない、無効、期限切れの場合は、CAPTCHAまたはChallengeレスポンスが返されます。

そのため、ブラウザではないクライアントに適用する場合は特に注意が必要です。

原因を特定する手順

発生条件を整理する

まず、403が発生した条件を整理します。

以下の情報を集めると、調査が進めやすくなります。

項目	確認内容
発生日時	いつ発生したか
対象URL	どのページ、どのAPIか
HTTPメソッド	GET、POST、PUT、DELETEなど
クライアントIP	アクセス元IP
User-Agent	ブラウザ、アプリ内ブラウザ、bot、監視ツールなど
入力内容	フォーム本文、検索語句、JSON、ファイルなど
発生範囲	全ユーザーか、一部ユーザーか
再現性	常に再現するか、条件付きか
直近の変更	WAF設定、アプリ改修、広告配信、タグ追加など

特にフォーム送信やAPI送信で403が出る場合は、送信内容によってWAFルールに引っかかっている可能性があります。

AWS WAFログでBlockを確認する

次に、AWS WAFログで action がBlockになっているリクエストを確認します。

該当する日時、URL、IPアドレスで絞り込み、403が発生したリクエストがAWS WAFでBlockされているかを確認します。

ここで該当リクエストが見つかれば、AWS WAFが原因である可能性が高くなります。

ブロックしたルールを確認する

AWS WAFログで該当リクエストを見つけたら、次に terminatingRuleId を確認します。

マネージドルールグループが原因の場合は、ruleGroupList や labels も確認し、グループ内のどの個別ルールが反応したのかを調べます。

この段階で、SQLi系、XSS系、SizeRestrictions系、Bot系、Rate-based rule、IP制限など、原因の方向性が見えてきます。

誤検知か正しいブロックかを判断する

ブロックされたリクエストが見つかったら、それが誤検知なのか、正しいブロックなのかを判断します。

たとえば、以下のようなリクエストは正しいブロックである可能性があります。

リクエスト内容	判断
明らかな攻撃文字列が含まれる	正しいブロックの可能性が高い
大量のログイン試行	正しいブロックの可能性が高い
不審なBotアクセス	正しいブロックの可能性が高い
既知の悪性IPからのアクセス	正しいブロックの可能性が高い

一方で、以下のような場合は誤検知の可能性があります。

リクエスト内容	判断
正常な問い合わせフォーム送信	誤検知の可能性あり
CMS管理画面でのHTML投稿	誤検知の可能性あり
自社の監視ツール	誤検知の可能性あり
広告審査botや検索エンジンbot	誤検知の可能性あり
社内IPやVPNからのアクセス	設定ミスの可能性あり

誤検知だった場合の対処法

個別ルールをCountに変更する

AWS Managed Rulesで誤検知が発生している場合、まず検討すべきなのは、該当する個別ルールをCountに変更することです。

Countは、リクエストを検知して記録するものの、ブロックはしない動作です。

ただし、注意点があります。

マネージドルールグループ全体をCountにする方法と、ルールグループ内の個別ルールをCountにする方法は挙動が異なります。

誤検知調査では、ルールグループ全体を緩めるのではなく、問題になっている個別ルールをCountに変更するのが基本です。

これにより、防御範囲を大きく落とさず、問題のあるルールだけを調整できます。

スコープダウンステートメントで対象を絞る

スコープダウンステートメントを使うと、ルールの適用対象を絞ることができます。

たとえば、特定のURL、HTTPメソッド、ヘッダー、IPアドレス、国、クエリ文字列などを条件にして、WAFルールを適用する範囲を調整できます。

よくある調整例は以下です。

調整例	内容
管理画面だけ一部ルールを除外	CMS投稿時の誤検知を防ぐ
アップロードAPIだけ条件を変更	ファイル送信時の誤検知を防ぐ
問い合わせフォームだけ個別調整	正常な問い合わせを通す
社内IPだけ許可	管理作業時の403を防ぐ
ログインページだけRate制限	攻撃対象になりやすい箇所に絞る

重要なのは、WAF全体を緩めるのではなく、問題が起きている範囲だけを限定的に調整することです。

Allowルールを追加する

正規のアクセス元が明確な場合は、Allowルールを追加する方法もあります。

たとえば、社内IP、VPN、監視ツール、外部連携サービス、決済サービスなどが該当します。

ただし、Allowルールは慎重に設計する必要があります。

Allowルールを上位に置くと、その条件に一致したリクエストは後続のマネージドルールを通らずに許可されます。

そのため、条件を広くしすぎると、本来ブロックすべき攻撃まで通してしまう可能性があります。

Allow条件は、できるだけ狭く設定します。

IPアドレスだけでなく、パス、HTTPメソッド、認証ヘッダー、署名検証、APIキーなどと組み合わせると安全性が高まります。

Rate-based ruleのしきい値を見直す

Rate-based ruleが原因の場合は、しきい値や集約条件を見直します。

たとえば、以下のような調整が考えられます。

対処	内容
しきい値を上げる	正常アクセスを巻き込まないようにする
対象URLを絞る	ログインや検索など特定箇所だけに適用する
正常IPを除外する	監視ツールや社内IPを除外する
集約キーを見直す	IP以外の条件で制御する
BlockではなくChallengeを使う	いきなり拒否せず判定を挟む

広告配信やキャンペーンによりアクセスが急増するサイトでは、通常時のしきい値だけで判断すると、正常ユーザーを巻き込む可能性があります。

Bot Controlの設定を見直す

Bot Controlが原因の場合は、ブロックされたアクセスが本当に悪性Botなのかを確認します。

正常な検索エンジンクローラー、広告審査bot、外部監視ツール、E2Eテスト、外部API連携などが含まれていないか確認しましょう。

正常なアクセスであれば、IP、パス、User-Agent、ラベル、認証条件などを組み合わせて、必要最小限の例外を作ります。

User-AgentだけでAllowするのは避けたほうが安全です。

User-Agentは簡単に偽装できるためです。

CAPTCHAやChallengeの対象を見直す

CAPTCHAやChallengeは、一般ユーザー向けのブラウザアクセスには有効な場合があります。

一方で、API、Webhook、監視ツール、外部連携サービスには向いていません。

そのため、CAPTCHAやChallengeを設定する場合は、対象を慎重に分ける必要があります。

対象	向き不向き
ログインページ	向いている
会員登録フォーム	向いている
問い合わせフォーム	場合による
API	基本的に不向き
Webhook	不向き
監視ツール	不向き
決済連携	不向き

ブラウザユーザーとシステム連携を同じルールで扱うと、正常な連携処理が失敗する可能性があります。

ケース別の対処法

問い合わせフォームで403になる場合

問い合わせフォームで403が出る場合、本文や入力内容がWAFルールに引っかかっている可能性があります。

よくある原因は以下です。

原因	内容
XSS系ルール	HTMLタグやURLを含む本文
SQLi系ルール	SQL風の文字列を含む本文
SizeRestrictions	長文、Cookie肥大化、大きなBody
Bot対策	フォーム連投、Bot判定
Rate-based rule	同一IPからの連続送信

対処としては、まずWAFログで該当リクエストを確認し、ブロックした個別ルールを特定します。

誤検知であれば、問い合わせフォームのPOSTリクエストに限定して、該当ルールをCountにする、またはスコープダウンで対象を調整します。

ただし、問い合わせフォームは攻撃対象になりやすいため、WAFを大きく緩めすぎないことが重要です。

WordPressやCMS管理画面で403になる場合

WordPressやCMSの管理画面では、HTML、JavaScript、iframe、JSON、ショートコードなどを扱うことがあります。

そのため、投稿保存、固定ページ編集、テーマ設定、プラグイン設定、REST API、admin-ajax.phpなどでAWS WAFが反応することがあります。

この場合、以下の原因が考えられます。

原因	内容
XSS系ルール	HTMLやscript風の文字列
SQLi系ルール	投稿内容や設定値の文字列
SizeRestrictions	大きな投稿本文やCookie
REST API	JSON送信時の誤検知
セキュリティプラグイン	アプリ側でも403を返している可能性

管理画面だけWAFを緩める場合は、IP制限やVPN、Basic認証など別の防御と組み合わせるのが安全です。

一般公開ページと管理画面は、リスクも正常な入力内容も異なるため、同じWAF条件で扱わないほうがよい場合があります。

APIで403になる場合

APIでAWS WAFの403が出る場合、JSON Body、認証ヘッダー、Rate-based rule、Bot Control、CAPTCHA/Challengeなどが原因になることがあります。

APIはブラウザアクセスとは異なるため、CAPTCHAやChallengeとの相性がよくありません。

また、特定のAPIクライアントから短時間に多数のリクエストが発生する場合、Rate-based ruleに引っかかることもあります。

APIでは、WAFだけに頼るのではなく、認証、認可、APIキー、署名検証、レート制限、入力バリデーションなどを組み合わせて保護することが重要です。

広告LPで403になる場合

広告LPで403が出る場合、マーケティング施策に直接影響します。

広告クリック直後のURLには、UTMパラメータ、クリックID、広告媒体固有のパラメータなどが付与されることがあります。

これによりクエリ文字列が長くなり、WAFルールに引っかかる場合があります。

また、広告タグや解析タグによってCookieが増え、SizeRestrictions系ルールに影響することもあります。

さらに、広告審査botやSNSアプリ内ブラウザ、計測ツール、外形監視ツールがBot ControlやChallengeの影響を受ける可能性もあります。

広告LPで確認すべきポイントは以下です。

確認項目	理由
UTM付きURL	クエリ文字列が長くなる
クリックID	媒体固有パラメータが付与される
Cookieサイズ	タグが多いと肥大化する
Bot Control	広告審査botが影響を受ける可能性
Challenge	アプリ内ブラウザで失敗する可能性
Rate-based rule	配信直後にアクセスが急増する
Geo Match	海外審査拠点からのアクセスが弾かれる可能性

広告LPでは、WAFログだけでなく、広告審査状況、CVR、フォーム送信数、直帰率、計測タグの発火状況もあわせて確認するとよいです。

監視ツールで403になる場合

外形監視ツールや死活監視ツールが403になる場合、User-Agent、IP制限、Rate-based rule、Bot Control、Challengeなどが原因になっている可能性があります。

監視ツールは通常のブラウザとは異なるリクエストを送ることが多いため、Botと判断される場合があります。

この場合は、固定IP、専用User-Agent、専用の監視URL、認証ヘッダーなどを組み合わせて、必要最小限のAllow条件を作るとよいです。

User-Agentだけで許可するのは避けるべきです。

設定変更時の注意点

WAF全体を無効化しない

緊急対応として一時的にWAFを外す判断が必要になる場面もあります。

しかし、恒久対応としてWAF全体を無効化するのは避けるべきです。

WAF全体を無効化すると、403は解消されるかもしれませんが、SQLインジェクション、XSS、Botアクセス、不審IP、大量リクエストなどへの防御も同時に失われます。

まずは、問題になっているルール、URL、メソッド、IP、ヘッダーなどを特定し、最小限の範囲で調整することが重要です。

マネージドルールグループ全体を外さない

AWS Managed Rulesの一部ルールが誤検知しているだけなのに、ルールグループ全体を無効化するのは避けたほうがよいです。

たとえば、XSS系の個別ルールだけが問題なのに、Common Rule Set全体を無効化すると、他の重要な防御まで外れてしまいます。

基本的には、問題になっている個別ルールだけをCountにする、または対象パスだけスコープダウンする方法を検討します。

Allowルールの優先順位に注意する

AWS WAFでは、ルールの評価順序が重要です。

AllowやBlockなどの終端アクションに一致すると、後続ルールの評価は行われません。

そのため、特定IPを確実に許可したい場合は、Block系ルールより前にAllowルールを配置する必要があります。

ただし、Allowルールを上位に置くと、その条件に一致したリクエストは後続のマネージドルールを通らずに許可されます。

そのため、Allow条件はできるだけ限定的にする必要があります。

Countで検証してからBlockにする

新しいWAFルールを導入する場合や、マネージドルールを追加する場合は、いきなりBlockにするのではなく、Countで検証するのが安全です。

Countにしておけば、どのようなリクエストが検知されるかを確認しながら、正常ユーザーへの影響を事前に把握できます。

特に、ECサイト、問い合わせフォーム、会員登録、予約フォーム、資料請求フォーム、広告LPなどでは、WAFの誤検知が売上やコンバージョンに直結します。

本番でBlockにする前に、Count期間を設けて影響を確認することをおすすめします。

ユーザー向け403表示の改善

カスタムレスポンスを設定する

AWS WAFでは、Block時のレスポンスをカスタマイズできます。

デフォルトの403ページだけでは、ユーザーは何が起きたのか分かりません。

必要に応じて、以下のような案内を表示すると、問い合わせ対応がしやすくなります。

表示内容	推奨度
一般的なエラー案内	推奨
再試行の案内	推奨
問い合わせ先	推奨
発生時刻やリクエストID	推奨
ブロックされた具体的ルール名	非推奨
攻撃判定の詳細	非推奨
セキュリティ設定の詳細	非推奨

攻撃者に詳しい検知理由を見せるのは避けるべきです。

一方で、一般ユーザーが問い合わせしやすいように、リクエストIDや発生時刻を表示しておくと、運用側でログと照合しやすくなります。

ユーザー体験への影響も確認する

AWS WAFの403は、セキュリティ上は正しい動きであっても、ユーザー体験やビジネス上の成果に影響する場合があります。

特に、以下のページでは注意が必要です。

ページ	影響
問い合わせフォーム	リード獲得の機会損失
資料請求フォーム	CV低下
購入ページ	売上損失
会員登録ページ	登録率低下
ログインページ	サポート問い合わせ増加
広告LP	広告費の無駄、審査不備
予約フォーム	予約機会の損失

WAFの調整では、セキュリティだけでなく、フォーム送信率、CVR、広告審査、SEOクローラー、計測ツールへの影響も確認するとよいです。

実務で使えるチェックリスト

初動確認チェックリスト

AWS WAFによる403が疑われる場合は、まず以下を確認します。

チェック項目	確認内容
403は全ユーザーで出るか	全体障害か、一部ユーザーのみか
特定URLだけか	ページ、API、フォームを特定する
HTTPメソッドは何か	GETかPOSTか
発生日時はいつか	ログ検索の起点にする
クライアントIPは何か	該当リクエストを探す
User-Agentは何か	ブラウザ、bot、監視ツールを確認
直近でWAFを変更したか	ルール追加やManaged Rules更新を確認
直近でサイトを変更したか	フォーム、タグ、API、Cookieの変更を確認
広告配信を開始したか	流入増や広告審査botを確認
外部ツールを追加したか	解析、MA、ABテスト、チャットなどを確認

WAFログ確認チェックリスト

WAFログでは、以下を確認します。

ログ項目	確認内容
action	Blockになっているか
terminatingRuleId	どのルールが止めたか
terminatingRuleType	ルール種別は何か
ruleGroupList	マネージドルール内の個別ルール
labels	付与されたラベル
terminatingRuleMatchDetails	SQLiやXSSなどの詳細
httpRequest.clientIp	クライアントIP
httpRequest.country	国情報
httpRequest.uri	対象URL
httpRequest.args	クエリ文字列
httpRequest.headers	User-Agentなどのヘッダー
httpRequest.httpMethod	GET、POSTなど

対処方針チェックリスト

原因ごとの対処方針は以下です。

原因	主な対処
Managed Rulesの誤検知	個別ルールをCount化、スコープダウン
SQLi系ルール	入力内容を確認し、対象URLだけ調整
XSS系ルール	管理画面や投稿画面だけ条件調整
SizeRestrictions	Cookie、Body、Header、Queryを確認
IP制限	IP set、Allowルール、優先順位を確認
Geo Match	国判定、海外拠点、広告審査botを確認
Rate-based rule	しきい値、対象URL、集約キーを見直す
Bot Control	正常botや監視ツールを除外検討
CAPTCHA/Challenge	APIやWebhookには適用しない
広告LP	UTM、Cookie、Bot Control、Challengeを確認

やってはいけない対応

原因を調べずにWAFを無効化する

403を止めたいからといって、すぐにWAF全体を無効化するのは危険です。

攻撃を防いでいたルールまで外れてしまい、セキュリティリスクが高まります。

緊急対応が必要な場合でも、まずは該当ルールだけをCountにする、特定URLだけ例外化するなど、影響範囲を限定する対応を優先します。

ルールグループ全体を無効化する

AWS Managed Rulesの一部が誤検知しているだけの場合、ルールグループ全体を無効にする必要はありません。

個別ルールの調整、スコープダウン、対象パスの限定などで対応できるケースが多いです。

User-Agentだけで許可する

User-Agentは簡単に偽装できます。

そのため、User-Agentだけを条件にしてAllowするのは避けたほうがよいです。

監視ツールや外部連携を許可する場合は、固定IP、認証ヘッダー、専用パス、署名検証などと組み合わせるのが安全です。

本番環境でいきなりBlockにする

新しいルールを本番環境でいきなりBlockにすると、正常ユーザーを巻き込む可能性があります。

まずはCountで検知状況を確認し、問題がないことを確認してからBlockに切り替えるのが安全です。

AWS WAFの403を解消する基本方針

原因ルールを特定する

AWS WAFによる403対応では、まずブロックしたルールを特定します。

見るべきポイントは、action、terminatingRuleId、ruleGroupList、labels です。

原因ルールが分からないまま設定を変更すると、別の問題を引き起こす可能性があります。

必要最小限の範囲で調整する

AWS WAFの設定変更では、なるべく影響範囲を小さくすることが大切です。

全体を緩めるのではなく、以下のように限定して調整します。

調整単位	例
個別ルール	XSS_BODYだけCountにする
URL	問い合わせフォームだけ調整する
メソッド	POSTだけ対象にする
IP	社内IPだけ許可する
ヘッダー	特定の認証ヘッダーがある場合だけ許可する
API	特定エンドポイントだけ条件を変える

セキュリティとユーザー体験の両方を見る

AWS WAFはセキュリティを高めるための仕組みですが、誤検知が多いと正常なユーザーをブロックしてしまいます。

特に、問い合わせ、購入、登録、予約、資料請求などの重要導線では、403がビジネス上の損失につながります。

そのため、WAFログだけでなく、フォーム送信数、CVR、広告審査、SEOクローラー、監視ツール、外部連携の動作も確認することが大切です。

まとめ

AWS WAFが原因で403エラーが出る場合は、まず本当にAWS WAFがブロックしているのかを確認します。

そのうえで、AWS WAFログやSampled requestsを使い、どのルールがブロックしたのかを特定します。

特に重要なのは、以下の項目です。

確認項目	内容
action	Blockになっているか
terminatingRuleId	最終的に止めたルール
terminatingRuleType	ルールの種類
ruleGroupList	マネージドルール内の個別ルール
labels	検知カテゴリの手がかり
httpRequest	IP、URI、メソッド、ヘッダーなど

誤検知だった場合は、WAF全体を無効化するのではなく、問題になっている個別ルール、URL、メソッド、IP、ヘッダーなどに限定して調整します。

特に注意すべきポイントは以下です。

ポイント	内容
Count化	ルールグループ全体ではなく個別ルールを優先
Body検査	リソースごとに検査サイズ上限が異なる
CAPTCHA/Challenge	APIやWebhookには不向き
Rate-based rule	IP以外の集約キーも確認する
Sampled requests	全件ログではない
Allowルール	条件を狭くし、優先順位に注意する

AWS WAFの403対応では、セキュリティを落としすぎず、正常なユーザーを通すバランスが重要です。

そのためには、ログを確認し、原因ルールを特定し、必要最小限の例外設定を行うことが最も安全で実務的な対処法です。

以上、AWS WAFが原因で403エラーが出る場合の対処法についてでした。

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