WordPressのREST API経由で記事を投稿しようとしたら、403が返ってきました。返ってきたのはこの画面です。
“
閲覧できません (Forbidden access)
Powered by SiteGuard Lite
攻撃を受けたわけでも、サーバーが落ちたわけでもありません。自分のサーバーのWAFが、自分の記事を攻撃だと判定していました。
原因を特定するまでに3時間かかりました。そのうち2時間は、間違った仮説に費やしています。同じ構成で運用している方の役に立つと思うので、切り分けの手順ごと書きます。
前提
- ConoHa WING
- WordPress（ブロックテーマ）
- サイトセキュリティのWAFと、WordPressセキュリティのSiteGuard Liteが両方ON
- 記事はREST API（
POST /wp-json/wp/v2/posts）で投稿
管理画面から手で投稿している場合は起きません。APIやスクリプトから投稿している場合だけの話です。
まず間違えたこと
403が出たとき、最初にやったのは推測でした。本文のどこかに原因があるはずだと考えて、怪しそうな箇所を目で探したのです。見つかりませんでした。
次にやったのが段落を1つずつ投稿する方法です。50段落を個別に投げると、3段落だけが403になりました。その3段落を直しました。
それでも記事全体は403のままでした。
ここで分かったのは、段落を個別に投げるテストでは見つからないトリガーがあるということです。単体では通るのに、他の段落と一緒になると落ちる。組み合わせで発火します。
正しい切り分け方
先頭からの累積で二分探索します。
1段落目だけ、1〜2段落目、1〜4段落目……と範囲を広げながら投稿し、最初に403になる位置を探します。落ちた位置の段落を単体で投げると通ることがありますが、それでいいのです。知りたいのは「どこまで積むと落ちるか」です。
このとき必ずやるべきことが1つあります。対照を取ることです。
すでに投稿に成功している別の記事を、同じタイミングで投げてください。それが通れば、サーバー側の状態（回数制限やIP遮断）ではなく内容の問題だと確定します。私はこの確認を飛ばしたせいで、画像アップロードの403を「連続投稿の回数制限」だと断定し、10分間まったく効果のない再試行を繰り返しました。実際は内容依存でした。
また、本番のテンプレートや記事に対して試行錯誤しないでください。 私は切り分けの途中で本番の記事テンプレートを壊しました。使い捨ての対象を作って、そこで試してください。
実際に見つかったトリガー
最終的に、4種類が引っかかっていました。すべて実測です。
1. カンマのあとに and が来る英文
“
"hello" → 通る
"a, b, and c" → 403
"research, write, and publish" → 403
ルール名は 「SQLインジェクションからの防御２２（and/or,）」。カンマと and の並びが、SQLの条件式に見えるためです。英語の3項リストは普通この形なので、英語記事を書くと頻繁に当たります。
2. リンク2本を and でつないだ文の直後に、水平線
“`
[記事A](URL), and [記事B](URL).
—
“`
これで403になります。-- がSQLのコメント開始記号なので、URLと and と -- が揃うと攻撃の形に見えるようです。文を2つに割れば通ります。
3. 特定のPNG画像
画像をアップロードすると、一部のPNGだけが403になりました。ファイル名を変えても、サイズを変えて再描画しても、時間をおいても通りません。
JPEGに変換すると一発で通りました。 PNGの圧縮後のバイト列が、たまたまシグネチャに一致していたと考えられます。
“
sips -s format jpeg -s formatOptions 92 in.png --out out.jpg
4. CSSのコメント
テーマのスタイルを更新しようとしたら403。原因は /* */ でした。/* hello */ の1行だけでも落ちます。SQLのコメント記法と同じ形だからです。
ソース側にはコメントを残したいので、送信する直前にコメントだけ削る処理を入れて解決しました。
対処：WAFは切らない
一番やってはいけないのは、WAFをOFFにすることです。
同じ月、このWAFは実際のスキャン攻撃を200件以上遮断していました。自分の投稿を通すために切るのは、既知のリスクを、数分の手間と引き換えに増やす取引です。
正しい手順はこちらです。
- ConoHaコントロールパネル → サイト管理 → サイトセキュリティ → WAF → ログ
- 403になった時刻とURLの行を探す
- ルール名を確認する（ここに、何にマッチしたかまで出ています）
- 誤検出だと判断できたら、その行の 「除外」 を押す
除外するのはルール1つだけです。WAF全体はONのまま残ります。除外は後から取り消せますし、何を除外したか記録も残ります。
そして、最初からここを見ていれば早かった、という点も書いておきます。私が3時間かけて二分探索で突き止めたことは、最初からWAFのログに、マッチした文字列付きで出ていました。
まとめ
- 管理画面ではなくAPIから投稿している場合、WAFが本文を攻撃と誤判定することがある
- 段落を1つずつ試すテストでは見つからない。 組み合わせで発火するトリガーがある
- 先頭からの累積で二分探索する。必ず対照（成功実績のあるもの）を同時に投げる
- 本番のファイルで試行錯誤しない。使い捨ての対象を用意する
- 推測の前に、まずWAFのログを見る。 ルール名とマッチした文字列がそこにある
- WAFは切らない。該当ルールだけ除外する
AIエージェントに運用を任せていた3ヶ月の記録はこちら、サイトの数字そのものが測れていなかった話はこちらにまとめています。
編集・監修: 本記事は当サイト運営者が執筆し、内容を確認したうえで公開しています。記載した挙動はすべて、当サイト（ConoHa WING・WordPress）で2026年9月に実測したものです。他社環境での再現は保証しません。
本記事の内容は執筆時点の情報にもとづきます。サービスの仕様は変更される場合がありますので、詳しくは免責事項をご覧ください。