WordPressにWAFは必要？【設定手順と403エラーの直し方】

こんにちは。GMOプライム・ストラテジーの森岡です。

2026年7月、WordPress本体の脆弱性「wp2shell」で、更新までの応急処置としてWAFでの遮断が案内されました（出典：IPA、2026年7月）。ただ、引き継いだサイトのWAFがOFFのまま、というのはけっこうあります。

弊社GMOプライム・ストラテジーは、WordPressを高速かつセキュアに動かすサーバ環境「KUSANAGI」の開発元です。累計稼働台数は10万台を超え、公開している運用事例は200件以上あります。

読み終わるころには、自社サイトのWAFが「いま効いているか」を自分で確認できるようになっているはずです。

結論：WordPressサイトにWAFは必要です

結論、WordPressサイトにWAFは必要です。理由は、脆弱性が公表されてから更新が終わるまでの時間を、埋められるのがWAFだけだから。

とはいえ、「入れたから安心」ではありません。

Patchstackが2025年におこなったペネトレーションテストでは、一般的なホスティング環境の防御が、WordPress固有の脆弱性攻撃をブロックできた割合は12%でした。範囲を広げた2回目のテストでも26%です（出典：Patchstack「State of WordPress Security In 2026」2026年2月）。

つまりWAFは、入れれば9割止まる魔法の壁ではありません。守備範囲をわかったうえで、更新やログ確認と組み合わせて、はじめて効くものです。

WAFが防いでくれる攻撃

WAFが得意なのは、通信の中身に「攻撃のパターン」がはっきり出るタイプの攻撃です。

1. SQLインジェクション：データベースへの命令文を送り込んで、情報を抜いたり書き換えたりする攻撃
2. クロスサイトスクリプティング（XSS）：閲覧者のブラウザで、悪意のあるスクリプトを動かす攻撃
3. ディレクトリトラバーサル：公開していない設定ファイル（wp-config.phpなど）を読み取ろうとする攻撃
4. ブルートフォースアタック：ログイン画面に、総当たりでパスワードを打ち込む攻撃
5. 既知の脆弱性を狙った通信：特定のURLやパラメータを叩いてくる攻撃

共通しているのは、リクエストの中身を見れば「これは普通のアクセスじゃない」とわかる点です。

逆に言えば、そこが判別できない攻撃は苦手ということ。次章で解説します。

WAFでは防げない攻撃

こちらも正直に書きますが、WAFで止まらないものも、わりとあります。

1. IDとパスワードが盗まれたあとの、正規のログイン：本人と同じ通信なので、攻撃パターンが出ない
2. 権限を持つ人による内部からの改ざん：そもそも通っていい人の操作
3. Broken Access Control（権限管理の不備）を突く攻撃：認証済みの正常な通信に見える
4. サーバOSやミドルウェア層への攻撃：WAFはWebアプリ層を見ているので、範囲の外
5. バックアップやプラグイン更新を経由した汚染：入口が通信ではない

とくに3つ目が重要です。Patchstackのレポートによると、2025年にもっとも悪用されたのがこのBroken Access Controlの分類でして、攻撃が正常な認証済みトラフィックに見えるため、従来型のWAFでは防ぎにくいと指摘されています（出典：Patchstack「State of WordPress Security In 2026」2026年2月）。

「じゃあWAFを入れる意味なくない？」と思うかもですが、そうではありません。WAFが埋めるのは「時間」だから。ここは後半で詳しく書きます。

よくある質問：レンタルサーバのWAFがONなら、それで十分？

サイトによります。

ただ「最低限の入口は押さえられている」と考えるのが妥当かなと。

というのも、サーバ会社自身がそう書いているからです。たとえばwpX SpeedのWAF設定マニュアルでは、WAF設定は不正アクセスを100%駆除するものではなく、脆弱性に対する「最低限の予防策」である旨が明記されています。根本的な対応は最新版へのアップデート、とも書かれています。

なので、判断の順番はこうです。

いきなり高機能なWAFを探すより、いま持っているものが効いているかの確認が先。ここを飛ばす人が、ほんとうに多いです。

そもそもWAFとは？WordPressの「外側」で通信を止める仕組み

WAFとは、Webサイトに届く通信の「中身」を1件ずつ検査して、攻撃と判断したものだけを遮断する仕組みです。Web Application Firewall の略で、日本語だと「Webアプリケーションファイアウォール」。

ポイントは、WordPressに届く前に判定しているところ。ここが他のセキュリティ対策との違いを分けています。

WAFの仕組み：通信の中身をシグネチャと照合して遮断する

WAFは「シグネチャ」と呼ばれる定義ファイルを持っています。ざっくり言うと、攻撃のパターンを集めたリストです。

通信が届くと、WAFはその中身をリストと照らし合わせます。一致すれば遮断、しなければ通す。やっているのはこれだけ。

通信の流れで見ると、こんな感じです。

ここで大事なのは、シグネチャが更新され続けるものだということ。新しい攻撃手法が出れば、リストに追加されます。つまりWAFは、置いた瞬間から劣化していく装置でもあるわけです。

というのも、リストが古いままだと、新しい攻撃を素通りさせてしまうから。この話は、記事の後半の「運用」につながります。

ファイアウォールとの違い：見ているのが「経路」か「中身」か

同じではありません。見ている場所が違います。

• ファイアウォール＝IPアドレスとポート番号を見る。「誰が、どの入口から来たか」
• WAF＝HTTPリクエストの中身を見る。「何を持ち込もうとしているか」

空港でたとえると、ファイアウォールは入口ゲートです。通っていい人と時間帯を決める。いっぽうのWAFは保安検査場でして、通っていい人の荷物を開けて、危険物のリストと照合します。

※厳密には、ファイアウォールにも通信内容を見るタイプがあったりします。ここでは一般的なパケットフィルタ型を前提にしています。

要するに、ファイアウォールを通過した「正規の見た目の通信」から、危ないものを抜き出すのがWAFの役割。だから両方いる、というわけです。

IPS/IDSとの違い：守る範囲がサーバ全体かWebアプリか

IDSは「検知するだけ」、IPSは「検知して遮断もする」もの。なのでIDSは見張り番、IPSはガードマンのようなイメージです。守る範囲は、ネットワークからサーバ全体まで広くカバーします。

対してWAFは、Webアプリケーション層に特化しています。範囲は狭いぶん、Web特有の攻撃にはよく効く。

• IPS/IDS＝サーバ全体への不審な通信・挙動を見る
• WAF＝Webアプリに届くリクエストの中身を見る

なのでどちらが良いというものではなく、重ねて使うのが一般的です。
ちなみにGMOプライム・ストラテジーが開発・提供しているWordPress専用OSである KUSANAGIでは、WAFとIPS/IDSの両方が標準で入っています。

セキュリティプラグインとの違い：WordPressの外か中か

いちばん混同されるのがここ。違いはシンプルで、WordPressの外で止めるか、中で止めるかです。

	ファイアウォール	WAF	IPS/IDS	セキュリティ プラグイン
見ているもの	IPアドレス・ポート番号	通信の中身	通信・サーバの挙動	WordPress内部の動き
守る範囲	サーバへの通信経路	Webアプリケーション	ネットワーク〜サーバ全体	WordPressのファイル・DB
判定する位置	サーバの手前	WordPressに届く前	サーバの手前・内部	WordPressの中
得意なこと	不要な通信の遮断	SQLi・XSSなどの遮断	不審な挙動の検知	ログイン保護・改ざん検知

セキュリティプラグインが得意なのは、ログイン試行の制限、改ざん検知、マルウェアスキャンなど。WordPressの中に入られたあとを見る役割です。

なおプラグイン型のWAFもありますが、これは「中で動くWAF」です。PHPが起動したあとに判定するため、攻撃通信はいったんサーバに到達します。なので負荷の面では、外で止めるタイプに分があります。

WordPressをWAFなしで運用すると危ない理由

理由は以下3つ。

1. 脆弱性の数が多い
2. 公表から攻撃までが速い
3. すぐに更新できない事情がある

順番に見ていきましょう。

脆弱性の9割はプラグインとテーマから出ている

まず数字から。

Patchstackの調査によると、2025年にWordPressのエコシステム全体で見つかった脆弱性は11,334件。前年比42%増で、過去最多です。うち91%がプラグイン、9%がテーマに起因していて、WordPress本体（コア）で報告されたのは6件、いずれも低リスクでした（出典：Patchstack「State of WordPress Security In 2026」2026年2月）。

なぜ狙われるのか。

単純に、母数が大きいからです。W3Techsによると、WordPressは全Webサイトの41.2%、CMSを使っているサイトに限れば59.1%を占めています（2026年7月時点）。ひとつ穴を見つければ、大量のサイトを効率よく攻撃できるわけです。

ここでわかるのは、「本体を最新にしていれば安心」ではないということ。危ないのは、ほとんどが拡張機能のほうです。

脆弱性が公表されてから攻撃が始まるまで、数時間しかない

この記事で、いちばん伝えたいところ。

同じPatchstackのレポートでは、実際に激しく悪用された脆弱性について、公表から最初の攻撃までの加重中央値は 5時間でした。高影響の脆弱性のおよそ半数が、24時間以内に悪用されています。

さらに厳しいのが、46%の脆弱性は公表の時点で修正版が出ていないという事実。開発者のパッチを待っているあいだ、サイトは開いたままになります。

2026年7月のwp2shellが、まさにそれでした。時系列で見ると、以下のとおり。

• 7月17日：修正版7.0.2 / 6.9.5 / 6.8.6を緊急リリース、CloudflareがWAFルールを配信
• 7月19日：国産WAFのScutumが対応
• 7月22日：IPAが注意喚起を公開

このとき、更新までの緩和策として案内されたのが、WAFで

/wp-json/batch/v1

と

?rest_route=/batch/v1

を遮断することでした（出典：GMO Flatt Security Blog、2026年7月）。専門機関が「まずWAFで止めろ」と言った、ということです。

弊社代表の吉政も、脆弱性の発見から約4時間ほどで、攻撃が多方向から一斉に展開されるケースを観測している旨をコラムに書いています（2026年8月）。

ざっくり言うと、WAFは「守る装置」というより「時間を買う装置」。更新が終わるまでの数時間から数日を、代わりに耐えてくれるものだと思っています。

すぐに更新できないサイトほど、WAFで時間を稼ぐ必要がある

「じゃあ、すぐ更新すればいいのでは？」と思いますよね。おっしゃるとおりです。ただ、現場だとそうもいかない。

更新が止まる理由は、だいたいこのあたり。

• 検証環境がなく、本番で試すしかない
• テーマやプラグインにカスタマイズが入っていて、壊れるのが怖い
• 更新に上長や情シスの承認がいる
• 担当者が兼務で、そもそも手が空かない
• 繁忙期で、サイトを触れない

ぶっちゃけ、移設のご相談をいただいて環境を確認すると、更新が止まっている理由は技術的なものより承認フローや体制の話であることが多いです。金曜の夕方に緊急パッチが出ても、月曜まで動けない会社はふつうにあります。

だからこそ、更新が遅れがちなサイトほどWAFの価値が上がる。動けない時間を、WAFに肩代わりしてもらう。そういう位置づけです。

WordPressで使えるWAFは3タイプある

WordPressで使えるWAFは、以下の3つ。

1. レンタルサーバ付属
2. WordPressプラグイン
3. クラウド型

まずは1が入っているかを確認すればOKです。

レンタルサーバに標準搭載されているWAF

いちばん手軽なのが、これ。多くの共用サーバで、標準または無料オプションとして用意されています。

管理画面の「セキュリティ」あたりから、ドメイン単位でON/OFFを切り替える形が一般的。数クリックで終わります。

ひとつ覚えておいてほしいのが、設定の反映に5分から10分ほどかかるサーバが多いこと。切り替えた直後に確認しても変わっていないので、待つ必要があります。この時間差が、あとで出てくる「戻し忘れ」の温床になるので。

向いているのは、コーポレートサイトやオウンドメディアなど、まず最低限を押さえたいサイト。というか、契約しているなら使わない理由はないです。

WordPressプラグインとして入れるWAF

SiteGuard WP PluginやWordfenceなど、管理画面から入れられるタイプ。

強みは、WordPress固有の攻撃に強いことです。ログイン画面のURL変更、ログイン試行の制限、二要素認証など、一般的なWAF製品ではカバーしにくい部分に手が届きます。

いっぽうで、弱点もあります。

• PHPで動くため、アクセス数によってはサーバに負荷がかかる
• 無料版だと、防御ルールの更新が遅れる製品がある
• WordPressが起動したあとに判定するので、攻撃通信はサーバまで届いている

なので、プラグイン型は「単独で使うもの」というより「サーバ側のWAFに足すもの」と考えるのが現実的かなと思います。

サーバの手前に置くクラウド型WAF

CloudflareやAWS WAFなど、サイトとサーバのあいだに入るタイプ。DNSを切り替えるか、インフラ側で構成します。

最大の強みは、新しい脅威への対応が速いこと。wp2shellのときも、Cloudflareは修正版が公開された当日にWAFルールを配信しています。自社で何もしなくても、防御ルールが更新され続けるのは大きい。

とはいえ、設定には専門知識がいります。誤検知が起きたときも、サーバ側なのかクラウド側なのかの切り分けが増えるので。

	サーバ付属	プラグイン型	クラウド型
判定する位置	サーバ側	WordPressの中	サーバの手前
費用の目安	無料〜標準搭載	無料〜年間数万円	月額数千円〜
導入の手間	数クリック	インストールのみ	DNS切替・設定
WordPress固有の攻撃	中	強い	中〜強い
サーバ負荷への影響	小さい	かかる	小さい
向いているサイト	まず最初の1層	ログイン保護を足したい	止まると困る基幹サイト

※機能や価格は変わります。2026年8月時点の一般的な傾向として書いているので、詳細は各サービスの公式サイトをご確認ください。

WordPressでWAFを設定する手順

手順は4つです。

手順①：いま使っているサーバのWAFがONになっているか確認する

ご利用のサーバがレンタルサーバなどの共用サーバの場合、管理画面にログインして、「セキュリティ」や「WAF設定」といった項目を探します。名称はサーバごとに違うので、見つからなければ公式マニュアルを参考にしてください。

確認するポイントは2つ。

1. ドメイン単位でON/OFFが分かれている場合 → 全部のドメインでONになっているか（1つだけ設定し忘れてOFFのまま、というケースがある）
2. www ありと www なし → 両方ともONになっているか（片方だけ設定して、もう片方を見落としているケースがある）

ここでOFFになっていたら、今日いちばんの収穫です。理由はあとで書きますが、OFFのまま何年も動いているサイトは、けっこうあるからです。

手順②：検知のみのモードにして、数日ログを見る

クラウドサーバであるAWSののサービスである、AWS WAFなど、モードを選べるWAFなら、まず「Count（検知のみ）」で動かします。いきなりブロックにしない。

目的は、自社サイトの正常な操作が引っかからないかを、先に見ておくことです。数日ログを眺めると、どのルールが反応しやすいかがわかります。

サーバ付属のWAFでモードが選べない場合は、この手順は飛ばして③へ進んでOKです。

手順③：ブロックに切り替えて、管理画面の操作をひと通り試す

ブロックにしたら、必ずこの4つを試してください。誤検知が起きやすい操作です。

1. 記事の保存・更新（とくに英文やコードを含むもの）
2. 画像・ファイルのアップロード
3. カスタマイザーやHTMLタグ設定へのスクリプト貼り付け（広告タグ、解析タグなど）
4. お問い合わせフォームの送信

とくに③は事故が多いです。広告タグを貼ろうとして403が出る、というのは定番です。

手順④：除外設定とログ確認の担当・頻度を決める

ここまでやったら、最後に決めごとを作ります。

• 誰がログを見るか
• どのくらいの頻度で見るか（月1回でも十分）
• 除外設定を入れたら、理由と日付をどこに残すか

紙一枚、あるいは社内のドキュメントに1行でいいです。ここを決めないと、担当が変わった瞬間にブラックボックスになります。

注意点：本番サイトでいきなりブロックに切り替えない

前述していますが、WAFには大きく分けて2つの動き方があります。

• 検知のみモード（Countなど）：怪しい通信を見つけても、ログに記録するだけ。実際の通信は止めない
• ブロックモード：怪しい通信を見つけたら、実際にそのリクエストを遮断する（＝ユーザーには403エラーが表示される）

検知のみモードのあいだは、たとえ誤検知（正規の操作なのに攻撃と誤って判定すること）が起きても、ログに残るだけで実害はありません。

ですが、ブロックモードに切り替えた瞬間、記事の保存ができない、フォームが送信できない、広告タグが貼れない、などが確認なしにいきなり本番で起きてしまうわけです。

だからこそ、切り替え方には注意が必要です。検証環境があるなら、そちらで先にブロックモードを試すのが安全です。検証環境がない場合は、営業時間内かつアクセスの少ない時間帯に切り替えてください。何かあったときに、すぐ気づいて戻せる時間帯であることが大事だからです。

あと、繰り返しですが反映には時間がかかります。切り替えて「変わってないな」と思っても、5分から10分は待ってから判断しましょう。

WAFの誤検知で403エラーが出たときの対処

結論、WAFをOFFにするのではなく、ログで検知ルールを特定して、その通信だけ除外します。

OFFは切り分けのための一時的な手段でして、そのまま運用するものではありません。ここ、ネット上の情報がけっこう危ないので、ていねいに書きます。

まず確認すること：本当にWAFが原因かを切り分ける

403エラーの原因は、WAFだけではありません。

• .htaccessの記述ミス
• ファイルやディレクトリのパーミッション
• セキュリティプラグインによるブロック
• サーバ側のアクセス制限（IP制限、国別制限など）

なので、切り分けから始めます。手順はこう。

この「診断としてのOFF」は、正しい使い方です。問題は、このあと。

やってはいけない対処：WAFをOFFにして、そのまま戻さない

「WAF 403 エラー」で検索すると、「WAFをOFFにすればOK」という趣旨の情報がたくさん出てきます。実際それで作業は終わるので、解決したように見えます。

でも、これがいちばんまずい。

なぜ戻し忘れるのか。理由は、反映に5分から10分かかるから。待っているあいだに別の作業へ移り、そのまま一日が終わる。「戻す」というタスクだけが、記憶から消えます。

正直な話、移設のご相談をいただいて環境を確認すると、WAFがOFFのままだったサイトに何度も出会ってきました。多いのは、数年前に広告タグを貼ろうとしてOFFにしたきり、というパターン。

• 誤検知の調整をやる場合 → 数時間の作業
• OFFのまま放置した場合 → 数年間、無防備

さきほど書いたとおり、脆弱性は公表から5時間で攻撃が始まります。その5時間を吸収する層が、そもそも存在しない状態になっているわけです。

もし心当たりがあっても、自分を責めなくて大丈夫です。当時ネットに出ていた情報がそうだったからそれに従っただけ。いま戻せば、それで済みます。

正しい対処：ログから検知ルールを特定して、その通信だけ除外する

やることは4ステップ。

サーバ別・WAF設定画面とログの探し方

サーバごとに名称も場所も違うので、公式マニュアルを見るのがいちばん速いです。「（サーバ名） WAF 設定」で検索すれば、たいてい公式ページが出てきます。

一般的には、このあたりを探します。

• 管理画面の「セキュリティ」→「WAF設定」
• WAF設定画面の中の「ログ参照」「検知ログ」
• クラウド型なら、ダッシュボードの「Security Events」など

ひとつ実務的な注意点ですが、ログの保持期間が短いサーバがあります。直近1週間分しか見られない、というケースもしばしば。なので403が出たら、その日のうちにログを確認することをおすすめします。翌週に調べようとしても、証拠が消えてしまっています。

よくある質問：作業中だけOFFにするのはアリ？

アリです。ただし条件つきで。

• 作業の直前にOFFにする（前日にOFFにして寝ない）
• 作業が終わったら、すぐONに戻す
• ONになったことを、画面で確認する
• カレンダーかタスクに「WAFを戻す」を入れておく

とくに3つ目。反映に時間がかかるサーバでは、ONにした「つもり」のまま画面を閉じてしまいがちです。5分から10分待って、設定状態の表示が変わったのを目で見てください。

とはいえ、いちばんいいのはOFFにせず、除外設定で通す方向を先に試すこと。手間はすこし増えますが、戻し忘れという事故そのものが起きなくなります。

WAFを入れたあとに続ける運用

WAFは設置物ではなく、運用です。続けることは5つ。

やること	頻度の目安
本体・プラグイン・テーマの更新	月1回＋緊急時は即日
検知ログの確認	月1回
管理画面のIP制限・2要素認証	初回設定＋人事異動時
改ざん検知とバックアップの確認	月1回＋復元テストは年1回
不要なプラグイン・テーマの削除	四半期に1回

空欄は、そのまま社内で埋めて使ってみてください。

WordPress本体・プラグイン・テーマを更新し続ける

脆弱性の91%がプラグイン起因である以上、ここが本丸です。

理想は、検証環境（ステージング）で確認してから本番に反映する流れ。いきなり本番を更新して表示が崩れると、更新そのものが怖くなり、結果的に止まります。

なお、更新だけでは埋まらない部分もあります。繰り返しですが、46%の脆弱性は公表の時点でパッチが出ていないから。だから更新とWAFは、どちらかではなく両方必要です。

検知ログを定期的に確認する

見るポイントは3つ。

• 検知件数が急に増えていないか
• 同じIPアドレスから、繰り返し来ていないか
• 除外設定が、意図より広く効いていないか

頻度は月1回でも構いません。0回がいちばんまずい、というだけの話なので。

ちなみに、検知件数が増えたからといって、すぐ危なくなるわけではないです。むしろ「止まっている」証拠。慌てずに、傾向だけ見ておけばOKです。

管理画面にIP制限と2要素認証をかける

WAFで防げない「正規ログインを装った侵入」への対策が、ここ。

• wp-login.php や wp-admin へのIPアドレス制限
• 2要素認証の導入
• 使っていない管理者アカウントの削除

とくに最後。退職した人のアカウントが管理者権限のまま残っている、というのはあるあるです。人事異動のたびに見直してください。

改ざん検知とバックアップを用意する

改ざん検知は、ファイルが書き換わったときに気づくための仕組み。バックアップは、戻すための備えです。

ここで、正直な注意点を1つ。バックアップがあれば必ず戻せる、とは限りません。

Patchstackのレポートでは、サーバのメモリ上に残り続けるマルウェアが、掃除した直後のファイルを自動的に書き戻す事例が報告されています（2026年2月）。バックアップ自体がすでに汚染されているケースもある。

なので、世代を複数持つことと、年に一度は実際に復元してみることをおすすめします。試したことのないバックアップは、あるのと同じではないので。

使っていないプラグインとテーマを消す

停止しているだけでは、ファイルはサーバに残ります。脆弱性が見つかれば、狙われる対象になる。

地味ですが、減らすのがいちばん効く対策です。使っていないものは消す、それだけです。

---

ここまで読んで、「結局うちは何を入れればいいの？」と思いますよね。

正直に言うと、WAFに「これが正解」という答えはないです。

弊社が開発しているKUSANAGIにも、WAFは標準で入っています。オープンソースライセンスで提供しているので、使うこと自体は誰でもできる。ただ、サーバ環境を丸ごと入れ替える話でして、自前でやるならサーバ側の知識がガッツリ要ります。専門家が社内にいないと、正直むずかしいかなと。

じゃあ他のWAFはどうかというと、こちらも同じです。サイトの作り、月間PV、扱っている情報、使っているプラグイン、社内に技術がわかる人がいるかどうか。この組み合わせで、合う合わないが変わります。

なので本来おすすめしたいのは、いくつか試して、組み合わせて、自社に合う形を見つけること。サーバ付属だけで足りるサイトもあれば、クラウド型を足すべきサイトもある。誤検知の出方も環境ごとに違うので、こればかりは動かしてみないとわかりません。

……とはいえ、兼務でサイトを見ている方に「試して比べる」時間はありませんよね。試すには検証環境も要ります。

そこを丸ごと引き受けるために作ったのが「KUSANAGIマネージドサービス」です。WAFの選定から導入、誤検知のチューニング、その後の運用まで、サーバとWordPressの両方がわかるエンジニアが担当します。自分たちで試す時間がない方は、どうぞ。

まとめ

というわけで、今回は以上です。要点をまとめておきます。

この記事を閉じたら、

「サーバの管理画面を開いて、WAFがONかどうかを見る」

これだけやってみてください。3分で終わります。

ONだったら、それでOK。OFFだったら、今日いちばんの発見です。

なお、WAFを試して選ぶところから任せたい方は、KUSANAGIマネージドサービスもご覧ください。まずは無料で詳細を聞いてみることからでも大丈夫です。