Wordpress Post 403エラー｜トラブルシューティング

エラー概要

• https://www.tanaakk.com/wp-json/wp/v2/posts/18710?_locale=userというWordPress REST APIのエンドポイントへのPOSTリクエストが403 Forbiddenエラーとなっています。
• サーバーはawselb/2.0、つまりAWSの**Application Load Balancer (ALB)**によってリクエストが処理されています。
• リクエストは同一ドメイン内 (www.tanaakk.comから同じwww.tanaakk.comへのリクエスト) であるため、Cross-originの問題は今回発生していません

リクエストの流れ

① MacBookのブラウザ（Chrome）またはCurl (Terminal)
↓ HTTPS Request（POSTリクエスト）
② DNS（ドメインURL：www.tanaakk.comの名前解決）
↓
③ AWS ALB（Application Load Balancer）: HTTPS（443）
└ ここでエラー発生（403 Forbidden）
↓（ここで403のため、以下には到達しない）ログ確認・デバッグツール｜AWS EC2, S3
④ AWS WAF (Web Application Firewall)
↓ログ確認・デバッグツール｜AWS WAF
⑤ AWS Lightsailサーバー（Apache）SSL Lets Encrypt
↓ ログ確認・デバッグツール｜SSH
⑥ WordPressアプリケーション
↓ ログ確認・デバッグツール｜Chrome Developer Console
⑦ Web Server (Apache)
↓
⑧データベース（MySQL互換のMariaDB)

エラー結果のトラブルシューティングについて

今回のWordpress Post Updateに関するh2 ( )入力時の403エラーは文章をwordfileからコピーした場合に特定のh2タグ見出しエリアの半角カッコ()が原因であり、これはALBの自動生成ルールによるエラーということがわかりました。今回のエラーはおそらく、「(NAICS)」の表記（特に括弧付き）が偶然、AWSのマネージドルール（特にWordPress用のマネージドルール）に誤検知され、403エラーになったものです。

AWS WAFが特定の文字列や記号を含むHTTPリクエストを「攻撃の可能性がある」として過敏に検知・遮断することがあります。特にWordPressでは、REST API経由で記事内容をJSONで送信しますが、括弧や特殊記号を含む特定の文字列が、以下のようなAWS WAFのルールに誤ってヒットすることがあります。

• AWSManagedRulesCommonRuleSet
  一般的な攻撃手法（SQLインジェクションやXSS）に対するルール。
• AWSManagedRulesWordPressRuleSet
  WordPress特化型の攻撃対策ルールで、特定パターンをブロック。

例えば、括弧記号 ( ) はSQLインジェクションやスクリプト挿入系の攻撃に頻繁に利用されるため、AWS WAFのルールが過敏に反応してしまうケースがあります。

AIによってトラブルシューティングの質が変わった

ここまで来るのに1年前であれば、ドメイン、SSL、WAF、ロードバランシング、ブラウザ、Javascript、JSON、webサーバ、php、mySQLデータベース、ドメイン、セキュリティ、SREなどの専門家が複数いて、1週間以上かけないと解決できなかったような問題が、ほんの数十分で簡単に問題を特定できるようになっているという事実は、マーケットを大きく変えるということを立証しているでしょう。従前はエラーが発生した時に表面的な対応で諦めていたものが、根本的な原因まで特定できるようになりました。（ただし、根本原因がわかったとしても、結局Wordpress, Microsoft Word, AWS ELBという複数のサービスが噛み合った時のピットフォールのようなエラーなので、対処アクションを打つことはできず、結局()を当該h2見出しで使用しないということしかできなかったのですが、問題が明確になったことに価値があると思います。）