WordPressのセキュリティ対策｜公式が挙げる設定と優先順位

WordPressのセキュリティ対策を調べると、最初に出てくるのが「セキュリティ用のプラグインを入れる」という話です。ところが公式のドキュメントを読むと、プラグインの話は後ろのほうにしか出てきません。先に書かれているのは、更新を当てること、ログインの入り口を絞ること、壊れたときに戻せるようにすることの3つです。

しかも、具体的な数値まで書かれています。ファイルの権限はディレクトリが755、ファイルが644。設定ファイルは400または440で、置き場所はインストール先の1つ上の階層。バックアップは小規模なサイトなら週1回で、直近3〜5世代を場所を分けて保管する。決める材料は、すでに公開されています。

この記事では、WordPressの公式ドキュメント（Advanced Administration Handbook）の4つのページに書かれている内容だけを使って、手を付ける順番と設定値を整理します。扱うのは、自動更新の既定の挙動、手動で上げるときの手順、ログイン試行への対処、ファイルの権限、テーマとプラグインの出所、バックアップと復元です。特定のセキュリティプラグインの比較はしません。順位を付けるための公表値を持っていないためです。確認日は2026年11月13日です。

対策は「更新」「入り口」「復旧」の3つに分かれる

4つのページに書かれている項目を並べ替えると、3つの層になります。層にすると、どれから手を付けるかが決まります。

1層目は更新です。本体・テーマ・プラグインを最新の状態に保つことで、Hardening WordPressは「常に最新のWordPressに追随しておくべき」と書いています。ここが抜けていると、ほかの対策をいくら足しても、すでに公開されている不具合が残ります。

2層目は入り口です。ログインの試行と、ファイルを書き換えられる経路を絞ります。パスワード、2要素認証、試行回数の制限、ファイルの権限がここに入ります。

3層目は復旧です。侵入されたとき、更新で壊れたとき、操作を間違えたときに戻せるようにします。ここが無いと、1層目と2層目をやっていても、最後は作り直しになります。

更新：いま自動で入っているのはどこまでか

「更新は自動で入っているはず」と思っている現場が多い部分です。ところが既定の挙動は、そのサイトをいつ作ったかで違います。

Upgrading WordPressの記載では、WordPress 5.6以降に作られたインストールは、既定でマイナーとメジャーの両方の本体更新が自動で入ります。ただし、バージョン管理のチェックアウトが検出された場合は除きます。これに対してそれ以前から動いているインストールは、既定ではマイナーの本体更新と翻訳ファイルだけが自動です。

つまり、数年前に立てた企業サイトでは、メジャー更新が自分の手元に残っている可能性があります。管理画面の更新画面を開いて、どちらの状態になっているかを確かめるところからです。

挙動は設定ファイルの定数で上書きできます。値と意味は次のとおりです。

定数と値	ドキュメントに書かれている挙動
WP_AUTO_UPDATE_CORE に true	開発版・マイナー・メジャーのすべてを有効にする
WP_AUTO_UPDATE_CORE に false	開発版・マイナー・メジャーのすべてを無効にする
WP_AUTO_UPDATE_CORE に 'minor'	マイナーだけを有効にし、開発版とメジャーは無効にする
AUTOMATIC_UPDATER_DISABLED に true	自動更新のすべてを止める
定数を書かない場合	そのサイトの設定と、インストール時期による既定の挙動に従う

ここで注意したいのは、無効にする方向の設定について、ドキュメントが「強く推奨しない」と書いている点です。「更新で表示が崩れたことがあるから自動更新を止めた」という運用は、崩れる不安と、修正が入らない不安を取り替えているだけです。止めるのであれば、代わりに更新を当てる担当と頻度を決める必要があります。

更新で崩れるのが怖い場合に先に用意するのは、自動更新の停止ではなく戻せる状態です。3層目の話につながります。

手動で上げるときは、バックアップと全プラグインの停止が先

本体を手動で上げる手順についても、ドキュメントは順番を決めています。

まずバックアップです。Upgrading WordPressは「始める前に、サイトをバックアップしておくのがよい」と書いており、何か起きたときに元に戻せるからだと理由を添えています。手動で上げる手順の側には、データベースのバックアップ、.htaccess を含む全ファイルのバックアップ、そしてそのバックアップが使えるものかを確認することまでが並んでいます。

次にプラグインをすべて停止します。ドキュメントの表現は「すべてのプラグインを停止する」で、更新後、対応した版が出てから順に有効へ戻します。ここを飛ばして、動かなくなった原因がどのプラグインかを後から切り分ける作業は、かなり時間を取られます。

プラグインの入れ方そのものはWordPressのプラグインの選び方｜目的別の考え方と確認項目の側で扱っています。本記事は、すでに入っているものを更新のときにどう扱うかという話です。

入り口：ログイン試行は、サイトの外側で止める

ログインを狙う総当たり（ブルートフォース）について、Brute Force Attacksのページは対処を具体的に挙げています。

パスワードは強固で一意なものにし、パスワードマネージャーを使う。Hardening WordPressの側はさらに細かく、避けるべきパスワードとして、本名・ユーザー名・会社名・サイト名を並べ替えたもの、辞書にある語、短いもの、数字だけ・英字だけのものを挙げています。

ログイン試行は、エッジ（WAFやCDN）またはWebサーバー側でレート制限する。ここが、プラグインの話から入ると抜けやすい点です。ドキュメントは、エッジで止める利点を「サーバーに届く前に止まるため、大量の試行があってもサーバーの資源を使わない」と説明しています。

理由として押さえておきたいのが、成功しなかった試行でもサイトは重くなるという記載です。「突破されていないから問題ない」とは書かれていません。大量のリクエストでサイトが圧迫されること自体が、対処する理由になります。

残りの3点も、設定だけで済むものです。管理者アカウントには2要素認証を入れる。ドキュメントはここで「WordPress本体に2要素認証は含まれていない」と明記しており、プラグインか、使っているIDプロバイダ側で用意する前提です。ユーザー名に admin を使わない。別の管理者アカウントを作り、古いユーザーは権限を下げるか削除します。そして/wp-login.php へのアクセスをIPで制限する方法が、サーバー設定の例として示されています。

ファイルの権限は数値で決まっている

ファイルの権限は、議論ではなく数値で決まっている部分です。Hardening WordPressの記載は次のとおりです。

ディレクトリは755、ファイルは644。本体の自動更新が走るときも「すべてのファイルは0644、すべてのディレクトリは0755に設定され、書き込めるのは所有ユーザーだけ、読み取りはそれ以外にも許可される」状態になると書かれています。

ディレクトリごとの扱いも分かれています。/wp-admin/ と /wp-includes/ は所有ユーザーだけが書き込める状態、/wp-content/ はユーザーとWebサーバーのプロセスが書き込める状態、/wp-content/plugins/ は所有ユーザーだけ。/wp-content/themes/ は、管理画面の編集機能を使う場合だけWebサーバーから書き込める必要があり、使わないなら所有ユーザーだけにします。書き換え規則を自動で書かせたい場合の .htaccess も例外として挙げられています。

設定ファイルの扱いは、権限と置き場所の2つです。wp-config.php の権限は400または440。置き場所はインストール先の1つ上の階層が推奨されています。あわせて、.htaccess で wp-config.php へのアクセスを拒否する記述が例として載っています。

管理画面からファイルを編集できる状態も、入り口のひとつです。ドキュメントは define( 'DISALLOW_FILE_EDIT', true ); を設定ファイルへ置くことを挙げ、これは edit_themes、edit_plugins、edit_files の権限を外すことと同じだと説明しています。管理者のアカウントが乗っ取られたときに、その場でコードを書き換えられる経路が1つ減ります。

データベースの接頭辞についても記載があります。既定の wp_ から変えることで「少なくとも一部のSQLインジェクションを防げる」とされています。すべてを防ぐとは書かれていません。この書き方のまま受け取るのが安全です。

テーマとプラグインは出所を絞る

入れるものの出所についても、ドキュメントは範囲を指定しています。WordPress.orgの公式ディレクトリ、またはよく知られた企業のものに限るという記載です。

この一文は、無償で配られている有料テーマの改変版（いわゆる海賊版）を使わない理由にもなります。機能は同じように見えても、配布元が不明なコードが混ざる可能性があります。社内で誰でもプラグインを追加できる状態になっているなら、追加できる人を決めるところから手を付けます。

サーバー側で何が用意されているかも、確認する価値があります。WAFの提供、バックアップの自動取得、ログイン試行の制限は、サーバー会社の機能として用意されていることがあります。選ぶときの観点はWordPress向けサーバーの選び方｜企業サイトで確認する基準の側で扱っています。本記事では、各社がどこまで提供しているかという公表値は確認していません。

復旧：戻せない対策は対策ではない

バックアップの中身についても、ドキュメントは2つに分けています。ファイル（本体、テーマ、プラグイン、アップロードした画像、wp-config.php、.htaccess）と、データベースです。記事・コメント・リンクはデータベース側に入っており、通常はMySQLまたはMariaDBという別のシステムに置かれていると説明されています。

ファイルだけをコピーして「バックアップを取った」と考えている状態は、ここで崩れます。記事本文はファイルの側にありません。

頻度の目安も書かれています。投稿の少ない小規模なサイトは週1回、投稿の多いサイトは毎日。Hardening WordPressの側にも、インストール全体とデータベースの「週次のスナップショット」を信頼できる場所に置く、という記載があります。

保管のしかたについては、直近3〜5世代を、別々の場所に保管するという記載です。例として、借りているサーバー、クラウドストレージ、手元のパソコンの3か所が挙げられています。同じサーバーの中に3世代置いた状態は、この条件を満たしません。サーバーごと使えなくなる事態に備えられないためです。

自動で取る仕組みにしている場合の注意も1つあります。ドキュメントは、自動のバックアップについてもときどき手動でバックアップを取り、仕組みが動いていることを確かめることを強く推奨しています。取れているつもりで、中身が空のファイルが並んでいる状態は、復元しようとした日まで分かりません。

復元の順番を間違えない

戻すときの順番も決まっています。ファイルを先に戻し、そのあとデータベースを取り込みます。そして、データベースの名前やユーザー名、パスワードが変わっている場合は、wp-config.php の接続情報を合わせます。

ここは、慌てている場面で間違えやすい部分です。データベースだけを先に戻しても、テーマやプラグインのファイルが戻っていなければ画面は出ません。順番を手順書に書いておくと、当日に考えることが1つ減ります。

新しくサイトを立てる段階なら、この手順書を最初に作っておくほうが楽です。公開までの流れはWordPressの始め方｜準備から公開・初期設定までの手順の側で扱っています。

今回確認できなかったこと

一次情報で確かめられなかった項目は、埋めずに残します。

攻撃の件数や被害の金額といった統計は、今回参照した4つのページには載っていません。「WordPressサイトの何%が狙われている」といった数値を本記事に書いていないのは、確認できなかったからです。

セキュリティ用のプラグインについても、機能や料金を比較していません。順位やおすすめを出すには、並べ替えの基準になる公表値と確認日が必要で、今回はその材料を持っていません。ドキュメントが挙げているのは出所の範囲（公式ディレクトリ、またはよく知られた企業）までです。

2要素認証をどの手段で入れるかも扱っていません。本体に含まれていないことは記載されていますが、プラグインとIDプロバイダのどちらが適するかは、社内の認証の仕組みによって変わります。

サーバー会社がWAFやバックアップをどこまで提供しているかも、各社の公表情報を確認していません。契約している会社の仕様ページで確かめてください。

参照したのは英語のドキュメントです。日本語訳のページとの表記の違いは確認していません。本記事は法務やセキュリティ監査の助言ではありません。

まとめ

WordPressのセキュリティ対策は、プラグインを探す前に、公式ドキュメントが挙げている3層で整理できます。更新を当てる、入り口を絞る、戻せるようにする、の順です。

更新については、既定の挙動がサイトを作った時期で違います。5.6以降に作ったインストールはマイナーとメジャーの両方が自動、それ以前からのインストールはマイナーと翻訳ファイルだけが自動です。手動で上げるときは、使えることを確かめたバックアップと、全プラグインの停止が先に来ます。無効化の方向の設定は、ドキュメントが強く推奨しないと書いています。

入り口については、強固で一意なパスワードとパスワードマネージャー、管理者への2要素認証（本体には含まれない）、エッジまたはWebサーバーでのログイン試行のレート制限、admin というユーザー名を使わないこと、/wp-login.php のIP制限が挙げられています。ファイルの権限はディレクトリ755・ファイル644、wp-config.php は400または440で、置き場所は1つ上の階層。管理画面からの編集は DISALLOW_FILE_EDIT で止められます。

復旧については、ファイルとデータベースの両方を取り、小規模なサイトは週1回、投稿の多いサイトは毎日、直近3〜5世代を別々の場所に保管します。戻すときはファイルが先、データベースがあとです。自動で取っている場合も、ときどき手動で取って仕組みが動いていることを確かめてください。確認日は2026年11月13日です。