本文へスキップ
>_ITDITDセキュリティ対策プラットフォーム

フレームワーク別

WordPressのセキュリティ対策 — 本番ハードニング実務リファレンス

WordPressを安全に運用するための実務リファレンス。優先度つきハードニング・チェックリスト、更新・プラグイン管理・管理者認証(2FA)・管理画面の露出削減(xmlrpc/REST列挙)・wp-config と秘密・ファイル権限・HTTPS/バックアップ・依存の各対策、そして『自分のサイトが固まっているか』の自己検証まで。攻撃手順は載せず防御と点検のみ。

公開日 2026-07-02 更新日 2026-07-02 10分で読める

対象:WordPressでサイトを運営している人。ここでは攻撃手順は扱わず、本番を固めるための実務リファレンス(優先度つきチェックリスト・領域別対策・自己検証)を示します。フレームワーク全体の考え方は フレームワーク別セキュリティの入口 も参照。

優先度つきハードニング・チェックリスト

まずこの表を上から実施します。P0は最優先、P1が最頻の事故源、P2は継続的な運用衛生です。

P0 ── 前提(まずこれ)

自動更新 / 未使用プラグイン・テーマの削除 / 強い管理者+2FA

P1 ── 最頻の事故源

プラグイン最小化 / 管理画面の露出削減 / 戻せるバックアップ

P2 ── 運用衛生

wp-config と秘密 / ファイル権限 / HTTPS・ヘッダ・PHP/依存の鮮度

ハードニングは土台から積む。P0(前提)→P1(最頻の事故源)→P2(運用衛生)。
優先対策具体(WordPress)
P0自動更新本体・プラグイン・テーマの自動更新を有効化。メジャー更新前はバックアップ
P0未使用を削除使わないプラグイン/テーマは無効化でなく削除(残置ファイルも脆弱性対象)
P0強い管理者+2FA強パスワード+二要素認証。ユーザー名 admin を避け、権限は最小
P1プラグイン最小化導入前に更新頻度・実績・既知CVEを確認。数を絞る
P1ログイン保護ログイン試行制限。wp-admin/wp-login.php の露出を絞る
P1露出削減未使用なら xmlrpc.php 制限。REST APIのユーザー列挙を抑制
P1バックアップオフライン/別保管の戻せるバックアップ+復元テスト+改ざん検知
P2wp-config と秘密認証キー/ソルト設定・wp-config.php 保護・本番でデバッグ表示を無効
P2ファイル権限ファイル644/ディレクトリ755目安。アップロード先でPHP実行を禁止
P2HTTPS/ヘッダ/更新HTTPS強制・HSTS等。PHP/DBをサポート版に保つ

1. 更新(最優先の防御)

WordPressへの攻撃の多くは、公開済みの既知脆弱性(CVE)を自動化ツールが一斉に突くものです。だから更新の速さが最大の防御になります。

  • 本体・プラグイン・テーマの自動更新を有効化。公開された穴を突かれる前に閉じる。
  • 重要サイトはステージングでメジャー更新を検証し、更新前にバックアップを取る。
  • 放置された更新は、そのまま自動化攻撃の入口。更新を「後でやる」にしない。

2. プラグインとテーマ(攻撃対象領域)

第三者製コードの脆弱性は最大の入口です。数を絞り、放置しないのが要点。

  • 使っていないプラグイン/テーマは無効化でなく削除(無効でもファイルが残れば脆弱性の対象)。
  • 導入前に更新頻度・利用実績・最終更新日・既知のCVEを確認する。作者放棄されたものは避ける。
  • プラグインのCVEは CVE/KEVルックアップ でも確認できる。数を減らすほど、更新し続ける責任も攻撃面も減る。

3. 管理者アカウントと認証

乗っ取りの多くは、弱い/使い回しの管理者アカウントへの総当たりや漏洩パスワードの流用です。

やりがち(危険)

  • ユーザー名 admin+弱いパスワード+2FA無し
  • 全員が管理者権限(役割分担なし)
  • ログイン試行が無制限
  • wp-admin が誰からでも到達可能

正しい

  • 強いパスワード+2FA、ユーザー名は admin 以外
  • 役割は最小権限(編集者/投稿者を使い分け)
  • ログイン試行制限(総当たりを抑える)
  • 可能なら wp-admin/wp-login.phpアクセス元を制限

二要素認証の選び方は 二要素認証とは、狙われる経路は フィッシングとは を参照。

4. 露出を削る(管理面・情報開示)

攻撃者はまず「使える入口」を探します。使っていない機能や余計な情報開示を減らします。

  • ログイン試行制限を入れ、総当たりの実効性を下げる。
  • 未使用なら xmlrpc.php を制限(総当たり増幅や大量リクエストの入口になり得る)。
  • REST APIのユーザー名列挙を抑制する(?author= 等での管理者名露出を防ぐ)。
  • ディレクトリ一覧表示を無効化し、バージョン等の不要な開示を減らす。
  • 管理画面からのファイル編集を無効化DISALLOW_FILE_EDIT)=侵入後の改ざんを難しくする。

5. wp-config と秘密(P2)

  • 認証用ユニークキー/ソルトを設定し、wp-config.php適切な権限で保護(誰でも読める状態にしない)。
  • DB接続情報など秘密は公開面に出さない。バックアップやエクスポートを公開ディレクトリに置かない(→ 公開ディレクトリに秘密を置かない)。
  • 本番ではデバッグ表示を無効WP_DEBUG_DISPLAY を false 相当に)。エラーで内部情報を出さない。

6. ファイルとアップロード(P2)

  • ファイル権限の目安はファイル644/ディレクトリ755wp-config.php はさらに厳しく。誰でも書き込める状態にしない。
  • アップロードディレクトリでPHPを実行させない(Webシェル設置対策)。アップロードは種別・サイズを検証。
  • 改ざん検知(ファイルの変化監視)で、侵入後の変更に早く気づけるようにする。

7. HTTPS・ヘッダ・バックアップ(P2)

  • HTTPS強制+HSTS。混在コンテンツを解消する。
  • セキュリティヘッダを付与(自サイトの状態は セキュリティヘッダ診断 で確認)。
  • オフライン/改ざん不能なバックアップ+復元テストで「戻せる」状態を保つ(→ バックアップの基本)。ランサムや改ざんの最後の砦。

8. ホスティングと依存(P1〜P2)

  • PHP と データベースをサポート対象バージョンに保つ。EOL版を放置しない。
  • ホスティングのパッチ適用状況を把握する(共有ホスティングなら提供元の対応も含む)。
  • WAF等はあくまで補助。土台(更新・最小化・認証・バックアップ)を先に固める。

検証:自分のWordPressは固められているか

作ったら終わりでなく、点検して初めて完了です。以下は自分のサイトに対する防御的な自己チェックです。

1

秘密・設定が露出していないか

自分のドメインで /wp-config.php中身を返さないこと、バックアップ(.zip/.sql)や .env 類がURLで取れないことを確認。
2

管理者名やバージョンが漏れていないか

?author=1 等で管理者ユーザー名が露出しないか、ディレクトリ一覧が出ないかを確認。
3

ログイン保護と2FAが効くか

ログイン試行制限が働くか、管理者に2FAが有効かを確認。admin ユーザーが残っていないか点検。
4

更新・バックアップ・ヘッダ

自動更新が有効か、バックアップから実際に復元できるか、ヘッダ診断で HTTPS/HSTS 等が付くかを確認。

当サイトの視点:本体より『拡張と放置』を管理する

WordPressの守りで効くのは、派手な設定ではなく「拡張を増やしすぎない・放置しない」という運用規律です。プラグインは便利ですが、1つ増えるごとに更新し続ける責任も増えます。守りの重心は、上の表を上から潰し、更新を自動化し、プラグインを最小にし、強い認証と戻せるバックアップで守ること。WordPress特有に見えて、実は普遍的な基礎(依存の鮮度・公開面の最小化・認証・復旧)の適用です。

次に読む

よくある質問

QWordPressで最初にやるべきセキュリティ対策は何ですか?
A

優先度P0の3つです。(1)本体・プラグイン・テーマの自動更新を有効にし、公開済みの既知脆弱性(CVE)を突かれる前に閉じる、(2)使っていないプラグイン/テーマを『無効化』でなく削除して攻撃対象領域を減らす、(3)管理者アカウントを強いパスワード+二要素認証(2FA)で守り、ユーザー名 admin を避ける。この3つだけで、自動化された攻撃の大半を止められます。次に管理画面の露出削減とバックアップへ進みます。

Qプラグインはどこまで入れていいですか?
A

『必要最小限だけ』が原則です。プラグインは1つ増えるごとに攻撃対象領域と『更新し続ける責任』が増えます。導入前に更新頻度・利用実績・最終更新日・既知の脆弱性を確認し、使っていないもの・停止中のものは無効化でなく削除してください(無効でもファイルが残れば脆弱性の対象になり得ます)。テーマも同様です。

Qxmlrpc.php は無効化すべきですか?
A

使っていなければ無効化またはアクセス制限を推奨します。xmlrpc.php は外部投稿やピンバックに使われますが、総当たりの増幅や大量リクエストの入口にもなり得ます。使っている機能(一部アプリ連携等)がある場合は、必要なメソッドだけに絞るか、レート制限・IP制限で守ります。まず『自分が使っているか』を確認してから決めてください。

Qセキュリティプラグインを入れれば安全ですか?
A

セキュリティプラグインは補助になりますが、万能ではありません。土台(自動更新・プラグイン最小化・強い管理者認証・バックアップ・管理画面の露出削減)ができていない状態でプラグインだけ足しても穴は塞がりません。まず本ページのチェックリストを上から実施し、その上でログイン試行制限や改ざん検知などを補う位置づけで使うのが適切です。

Q最低限、何をすればいいですか?
A

(1)自動更新、(2)未使用プラグイン/テーマの削除、(3)管理者に強いパスワード+2FA、(4)ログイン試行制限と管理画面の露出削減、(5)オフラインで戻せるバックアップ+改ざん検知。この5つで自動化攻撃の大半は防げます。詳細は上のチェックリストと各セクションを参照してください。