WordPressは、世界でもっとも使われているCMSのひとつです。使っている人が多いということは、攻撃する側から見ても「狙う価値がある」対象が多いということでもあります。有名企業のサイトでなくても、機械的なスキャンやログイン試行は日常的に飛んできます。
ただ、対策の多くは特別な知識がなくても始められます。今回は、Webサイト健康診断の記事でも触れたセキュリティの項目を、もう少し具体的に掘り下げます。
なぜ「うちは狙われない」と思っていると危ないのか
「うちは小さい会社だから、狙われるほどの規模じゃない」。よく聞く言葉ですが、多くの攻撃は特定の会社を狙って行われるわけではありません。世界中のIPアドレスやドメインを機械的に巡回し、脆弱な設定や古いバージョンを探すbot(自動プログラム)による攻撃が中心です。会社の規模や知名度は、この種の攻撃にはほとんど関係がありません。
だからこそ、対策の考え方はシンプルです。狙われないようにするのではなく、「機械的な攻撃に対して、手間がかかる・成功しにくい状態」にしておく。この記事で紹介する項目は、そのための基本の積み重ねです。
ユーザー名を推測させない
WordPressには、初期状態のままだとユーザー名が外部から分かってしまう仕組みがあります。代表的なのが?author=1のようなURLです。管理画面のユーザーIDに数字を当てはめてアクセスすると、そのユーザーの投稿者アーカイブページにリダイレクトされ、URLにユーザー名(ログインIDに使われる文字列)が表示されてしまいます。REST APIのユーザー情報エンドポイントから同じように読み取れることもあります。
ユーザー名が分かること自体がすぐに被害につながるわけではありませんが、あとに続くログイン試行(パスワードだけ当てればよい状態)を助けてしまいます。対策としては、投稿者アーカイブを無効化する、リダイレクトをブロックする、REST APIのユーザー情報を非公開にする、といった設定をセキュリティ系プラグインや.htaccessで行います。あわせて、そもそも「admin」のような推測しやすいユーザー名を使わないことも基本です。
ログイン画面を"誰でも試せる"状態にしない
wp-login.phpは、WordPressサイトなら決まった場所にあります。ここに誰でもアクセスできる状態は、攻撃側にとって「まず入力欄を叩いてみる」入口を用意しているのと同じです。
有効な対策のひとつが、ログイン画面の手前にもう一段階、確認を挟むことです。サーバー側でBasic認証(IDとパスワードを別途要求する仕組み)をかけたり、SiteGuard WP Pluginのような画像認証(ひらがなの組み合わせなどを入力させる仕組み)を導入したりすると、機械的なログイン試行の多くをその手前で止められます。ログイン失敗が続いた場合に一定時間ロックする、試行回数を制限する設定もあわせて有効です。
WordPressだと分かりにくくしておく
ドメイン直下(ルートディレクトリ)にWordPress本体のファイルをそのまま置くと、URL構造やファイル配置から「WordPressで作られている」ことが外部から読み取りやすくなります。これ自体で即座に危険というわけではありませんが、攻撃の手がかりを減らすという意味では、配置を工夫する余地があります。
代表的な方法が、WordPress本体を専用のサブディレクトリにインストールし、ルート直下には最小限のファイルだけを置いて、そこからサブディレクトリの中身を読み込むようにする構成です。サイトの表示URLはこれまでどおりドメイン直下のままにしつつ、実際のファイルの置き場所は一段階分かりにくくできます。既存サイトに後から適用する場合は、パーマリンクやプラグインへの影響を確認しながら進める必要があるため、慣れていない場合は事前に相談することをおすすめします。
ログイン情報をシンプルにしない
ユーザー名とパスワードが単純だと、これまでの対策をどれだけ積み重ねても、最後の入口が弱いままになります。「会社名+西暦」のような推測しやすいパスワードや、複数のサービスで使い回しているパスワードは避けたいところです。
目安としては、英数字・記号を組み合わせた長めのパスワードを、サービスごとに個別に設定することです。覚えるのが難しい場合は、パスワード管理ツールを使う、あるいはWordPress標準のパスワード自動生成機能をそのまま使う方法もあります。管理者権限を持つアカウントは必要な人数だけに絞り、使わなくなったアカウントは残さないことも合わせて確認しておきたい点です。
WAFを常にONにしておく
WAF(Webアプリケーションファイアウォール)は、サイトへの不正なアクセスやよくある攻撃パターンを、サイトに届く前の段階で検知してブロックする仕組みです。多くのレンタルサーバーには標準でWAFの機能が用意されていますが、初期設定でOFFになっていたり、一部の項目だけ有効になっていたりすることがあります。
まずは契約しているサーバーの管理画面でWAFの設定状況を確認し、有効になっていない項目がないか見直します。サーバー側にない場合や、より細かく制御したい場合は、セキュリティ系プラグインやCDNサービス側のWAF機能を組み合わせる方法もあります。設定して終わりではなく、誤検知でお問い合わせフォームなど正常な通信まで止めていないか、時々確認することも忘れずに行いたいところです。
バックアップを、いつでも戻せる状態にしておく
どれだけ対策をしていても、被害を完全にゼロにできる保証はありません。だからこそ、何かあったときに「以前の状態に戻せる」ことが、最後の安全網になります。
バックアップは、サーバー側の自動バックアップだけに頼らず、UpdraftPlusやBackWPupのようなプラグインを使って、サイトのデータベースとファイルを定期的に取得しておくと安心です。バックアップ先は、サイトと同じサーバーだけでなく、外部のストレージ(クラウドストレージなど)にも保存しておくと、サーバー自体にトラブルがあった場合にも対応しやすくなります。
取っているだけで安心せず、実際に復元できるかを一度試しておくことも大切です。「バックアップはあるはずだが、いざというとき戻せるか分からない」という状態は、ないのとあまり変わりません。
WordPress・プラグイン・PHPを定期的に更新する
WordPress本体、テーマ、プラグイン、そしてサーバー側のPHPのバージョンは、古いまま放置すると、すでに知られている脆弱性がそのまま残った状態になります。更新は、新機能を使うためというより、見つかった不具合や弱点をふさぐための作業という側面が大きいです。
更新でサイトが崩れることを心配して、後回しにしてしまう会社も少なくありません。その場合は、更新前に必ずバックアップを取る、可能であればテスト環境で確認してから本番に反映する、という手順にしておくと、更新自体への不安が減ります。使っていないプラグインやテーマは、無効化するだけでなく削除しておくことも、管理対象を減らすという意味で有効です。
よくある質問
一度に全部やろうとせず、まずはログイン画面まわり(ユーザー名・パスワード・ログイン試行の制限)と、バックアップが取れているかの2つから始めるのがおすすめです。ここは被害の入口と被害後の戻し先にあたるため、優先度が高い部分です。
プラグインの数よりも、役割が重なっていないかを見るほうが大切です。ログイン防御・バックアップ・WAFはそれぞれ別の役割なので、機能が重複していないかを確認しながら、必要なものだけ残すと負荷を抑えやすくなります。
できます。今の設定状況やお使いのサーバー環境を共有いただければ、優先順位をつけて一緒に整理します。設定だけでなく、その後の更新やバックアップ確認まで含めて継続的に見ていくことも可能です。
セキュリティ対策は、一度設定して終わりではなく、更新や確認を続けていく必要がある領域です。となりのWeb担当では、日々の更新作業やトラブル対応とあわせて、こうした運用面のケアも継続して見ていきます。
Webコーダー/ディレクターとして独立後、2026年にI-to.合同会社を設立。Webサイト制作・コーディング代行・AIケアを通じて、社内のWeb業務を整理し、運用しやすい形に整えています。プロフィール詳細