2026年9月22日

WordPressのセキュリティチェックリスト：構築時・毎月・異変時に確認する項目

セキュリティ

WordPressのセキュリティ対策は、特別なプラグインを1つ入れることより「更新・アカウント・設定・バックアップ・監視」を漏れなく回すことで大半の被害を防げます。この記事では、構築時に一度だけ確認する項目、毎月の定期点検、異変に気づいたときの確認順をチェックリストの形で整理し、各項目を「なぜ必要か」「どう確かめるか」と合わせて説明します。

作業の前に、サイト全体（ファイルとデータベース）のバックアップを取り、設定変更はできればステージング環境で試してから本番に反映してください。

チェックリストの全体像

項目は大きく5つの領域に分かれます。

更新：WordPress本体・プラグイン・テーマ・PHPを、サポートされている状態に保つ
アカウント：管理者を最小限にし、強いパスワードと二要素認証で守る
設定：wp-config.php、ファイル権限、不要な機能の停止
通信と公開範囲：HTTPS、セキュリティヘッダー、デバッグ表示の停止
復旧と監視：バックアップの保管と復元テスト、改ざん・脆弱性の検知

攻撃の多くは、公開済みの脆弱性を持つ古いプラグインと、推測しやすいパスワードを狙った自動化されたものです。つまり上の2領域を押さえるだけで、受けるリスクはかなり下がります。残りは「侵入されにくくする」「侵入されても早く気づき、戻せる」ための層です。

構築時に一度だけ確認する項目

管理者アカウントとログイン

管理者権限のユーザーは必要な人数だけにする。記事を書くだけの人は「編集者」や「投稿者」にする
ユーザー名に「admin」やドメイン名など推測しやすいものを使わない
パスワードはパスワードマネージャーで生成した長いものにし、使い回さない
二要素認証を導入する。「Two Factor」「WP 2FA」、Wordfence に含まれるログインセキュリティ機能など、保守が続いている定番プラグインから選ぶ
ログイン試行回数の制限を入れる（「Limit Login Attempts Reloaded」など、またはサーバー側のWAF機能）

二要素認証を入れる前に、管理者自身が締め出されたときの戻り方を決めておきます。FTPやファイルマネージャーで該当プラグインのフォルダ名を変えれば、そのプラグインは無効になり通常のログインに戻れます。サーバーのファイルにアクセスする手段を確保してから有効化してください。

wp-config.php の設定

wp-config.php には、セキュリティに直結する定数をまとめて書けます。

// 管理画面からのテーマ・プラグインファイル編集を無効化
define( 'DISALLOW_FILE_EDIT', true );

// 本番ではエラーを画面に出さない（ログには残す）
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

// 管理画面とログインを HTTPS に限定
define( 'FORCE_SSL_ADMIN', true );

DISALLOW_FILE_EDIT は、仮に管理者アカウントを乗っ取られても、管理画面からPHPファイルを書き換えられる経路を1つ塞ぐためのものです。認証用キー（AUTH_KEY などの8つの定数）がインストール時のまま空や既定値になっていないかも確認します。値は WordPress.org の秘密鍵生成サービスで作り直せます。差し替えると全ユーザーが一度ログアウトされるため、作業時間を選んでください。

ファイル権限と不要な機能

一般的な目安はディレクトリ 755、ファイル 644。wp-config.php はサーバーの構成が許す範囲で 600 や 640 など、より狭くする
777 のディレクトリが無いかを確認する。書き込みが必要な場所は uploads などに限られます
XML-RPC を使っていない（Jetpack や外部投稿アプリで使わない）なら停止を検討する
使っていないプラグインとテーマは「無効化」ではなく削除する。無効化したままのファイルにも脆弱性は残ります。テーマは障害時の予備として既定テーマを1つだけ残すと安心です

毎月の定期点検

毎月1回、次の順で確認します。WP-CLI が使える環境なら、確認作業の多くをコマンドで済ませられます。

# 本体・プラグイン・テーマの更新有無
wp core check-update
wp plugin list --update=available
wp theme list --update=available

# 管理者権限を持つユーザーの一覧
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# 本体ファイルが公式配布物から変更されていないか
wp core verify-checksums

# WordPress.org 配布のプラグインのファイル検証
wp plugin verify-checksums --all

更新

更新は「溜めない」ことが大切です。WordPressのマイナーリリース（セキュリティ修正）は既定で自動更新されますが、プラグインとテーマは自分で有効にしない限り自動更新されません。プラグイン一覧から個別に自動更新を有効にできるので、影響の小さいものから有効にし、決済やフォーム、会員機能など止まると困るものはステージングで確認してから手動で更新する、という分け方が現実的です。

長期間更新が止まっているプラグイン（WordPress.org のページで最終更新日を確認できます）は、代替プラグインへの移行を計画します。PHPのバージョンも、サポートが終わったものを使い続けていないか、管理画面の「ツール」→「サイトヘルス」で確認できます。サイトヘルスはPHPのバージョンやHTTPSの状態についても警告を表示します（2026年10月現在）。

アカウントとログ

管理者一覧に見覚えのないユーザーがいないか、退職者や外部委託先のアカウントが残っていないかを確認します。不正なユーザー追加は侵入の典型的な痕跡です。アプリケーションパスワード（プロフィール画面で発行できる外部連携用のパスワード）も、使っていないものは取り消します。

検証結果の読み方

wp core verify-checksums で差分が出た場合、本体ファイルが書き換えられているか、不要なファイルが置かれている可能性があります。差分のファイル名を控えたうえで、後述の「異変に気づいたとき」の手順に進みます。プラグインの検証は WordPress.org で配布されているものだけが対象で、有料プラグインや自作プラグインは検証できない点に注意してください。

通信と公開範囲

サイト全体を HTTPS で配信し、HTTP からはリダイレクトする
セキュリティヘッダー（X-Content-Type-Options、Referrer-Policy、Content-Security-Policy など）を、サイトの動作を確認しながら段階的に追加する
HSTS を使う場合は、すべてのサブドメインが HTTPS に対応していることを確認し、短い max-age から始める
debug.log がブラウザから閲覧できる場所に残っていないか確認する。WP_DEBUG_LOG を使う場合は、ログの出力先を公開ディレクトリの外にするか、Webサーバー側でアクセスを拒否する

バックアップと復元テスト

バックアップは「取っている」だけでなく「戻せる」ことを確認して初めて意味があります。

ファイルとデータベースの両方を対象にする
保存先をサーバーと同じ場所だけにしない。サーバーごと侵害されたり障害が起きたりすると、同じ場所のバックアップも失われます
世代を複数残す。改ざんに気づくまで時間がかかると、直近のバックアップも汚染されていることがあります
数か月に一度、ステージングやローカルで実際に復元して、サイトが動くことを確かめる

プラグインで行うなら「UpdraftPlus」などの定番があり、レンタルサーバーの自動バックアップ機能と併用すると層が厚くなります。

脆弱性と改ざんの検知

自分のサイトに入っているプラグインの脆弱性情報を把握する手段を1つ用意します。Wordfence や Patchstack、WPScan などが脆弱性データベースと通知の仕組みを提供しています。無料で使える範囲や通知の条件は各サービスで変わることがあるため、導入時に公式の説明を確認してください。

セキュリティプラグインは、ファイル改ざんの検知やログイン保護をまとめて提供してくれる便利な道具ですが、更新とバックアップの代わりにはなりません。複数のセキュリティプラグインを同時に有効にすると、機能が重複して動作が重くなったり、誤検知で管理画面に入れなくなったりすることがあるため、役割を決めて絞ります。

異変に気づいたときの確認順

見覚えのないリダイレクト、管理者ユーザーの増加、検索結果への不審なページの表示などに気づいたら、次の順で動きます。

現状をバックアップする（証拠として残すため、復元用とは別に保管）
管理者全員のパスワードを変更し、不明なユーザーとアプリケーションパスワードを削除する
wp core verify-checksums やセキュリティプラグインのスキャンで、改ざんされたファイルを特定する
本体は公式のファイルで上書きし、プラグイン・テーマは公式配布物から入れ直す
認証用キーを作り直し、データベースのパスワードも変更する
侵入口になった可能性のあるプラグインを更新または削除し、サーバーのアクセスログで侵入経路を確認する

自力での調査が難しい場合や、個人情報を扱うサイトで情報漏えいの可能性がある場合は、早めに専門の業者や契約しているサーバー会社に相談してください。

まとめ

被害の多くは古いプラグインと弱いパスワードが原因。更新とアカウント管理を最優先にする
構築時は管理者の最小化・二要素認証・DISALLOW_FILE_EDIT・ファイル権限・不要なプラグインの削除を確認する
毎月、更新状況・管理者一覧・チェックサム検証を点検する
バックアップはサーバー外に世代で残し、定期的に復元テストを行う
異変時は現状保全→パスワード変更→改ざん特定→入れ直し→キー再生成の順で対応する