【XServerサイトセキュリティ】無料の脆弱性診断を設定してみた｜対象プランの見分け方と、WordPressで出た指摘6件の直し方

2026年10月13日から、エックスサーバーとXServerビジネスの一部プランで、脆弱性診断サービスXServerサイトセキュリティ が追加料金なしで使えるようになりました。

受託で管理しているWordPressのコーポレートサイト（XServerビジネス）で実際に設定し、初回の診断で出た指摘6件に対応しました。この記事では、そのときの手順と判断をまとめます。

サイトの運営者の了承を得て掲載しています。サイトが特定できる情報（ドメイン、ログイン名、URLの構成など）は伏せています。この記事の内容は2026年10月時点のものです。

何が変わったのか

エックスサーバーの公式のお知らせによると、対象プランでは1サーバーにつき1サイトまで、次のプランを追加料金なしで使えます。

• 無料提供は自動では有効になりません。 サーバーパネルから自分で設定する必要があります
• これまでの「Web改ざん検知」は、2026年10月13日で新規の受付を終了し、2027年10月13日で提供を終了します
• サイトセキュリティを設定すると、Web改ざん検知の自動診断は止まります。設定や診断の履歴は引き継がれないので、必要ならスクリーンショットなどで先に保存しておきます

無料のライトプランでできることは、公式サイトの料金表によると次のとおりです。

自分のプランが対象か：「ビジネス」の名前に注意

ここで一度つまずきました。「ビジネス」が2つあるからです。

• エックスサーバーの「ビジネスプラン」：個人向けのエックスサーバーの上位プラン。無料の対象
• 「XServerビジネス」：法人向けの別のサービス。こちらはスタンダードを含む全プランが無料の対象

逆に言うと、エックスサーバー（個人向け）のスタンダードプランは対象外です。このブログ自体はエックスサーバーのスタンダードなので、無料では使えませんでした。

見分け方は簡単で、管理画面の左上のロゴが「XServer Business」ならXServerビジネスです。サーバーパネルの「サイトセキュリティ」を開くと、対象のサーバーでは「無料提供　このサーバー（〇〇）の契約に含まれます。1サイトまで設定できます。」と表示されます。

設定の手順

1. サーバーパネルの「セキュリティ」→「サイトセキュリティ」を開く
2. 「無料提供」の表示を確認し、診断開始URLと通知先メールアドレスを設定する
3. 通知の条件を選ぶ（脆弱性診断・Web改ざん検知それぞれ「問題が見つかったとき」など）

詳しい手順は公式マニュアルにあります。

• ［エックスサーバー］XServerサイトセキュリティ
• ［XServerビジネス］XServerサイトセキュリティ

1サイトしか登録できない。どれを選ぶか

1つのサーバーに複数のサイトがある場合、無料で登録できるのは1つだけです。次の順で選ぶのがおすすめです。

1. 会社の顔になるメインのサイト
2. 問い合わせや応募など、入力欄のあるフォームがあるサイト（XSSやSQLインジェクションの診断は、入力欄があるページでこそ意味がある）
3. WordPressのサイト（プラグインの脆弱性が狙われやすい）

診断するページは選べない

設定画面にあるのは「診断開始URL」だけで、ページを1つずつ選ぶ欄はありません。診断開始URLからリンクをたどって、最大50ページを自動で診断する仕組みのようです。診断開始URLや診断の頻度は、あとから「診断パネル」で変更できます。

初回の診断が届くまで

設定したのが昼過ぎで、初回の結果がメールで届いたのは翌日の深夜2時台、約14時間後でした。自動診断は毎日1回なので、設定した日の夜に最初の診断が走ると考えておけばよさそうです。

届いたメールの見出しは「今すぐ対策が必要な問題が見つかりました。」。ドキッとしますが、中身を見ると、すぐに被害が出ているという意味ではありませんでした。メールの「詳細はこちら」から診断パネルに入ると、指摘ごとに「リスクについて」「推奨される対策」が書かれています。

出た指摘6件と、それぞれの直し方

診断の対象はWordPressのサイトで、指摘はすべて「WordPress診断」の分類でした。赤（重要）が2件、黄（注意）などが4件です。どれも、WordPressでよく指摘される「守りを固めたほうがいい箇所」でした。

以下のコードは、自分の環境で動作を確認したものの考え方を、一般的な形に書き直したものです。.htaccessやテーマのファイルを変える前に、必ずバックアップを取ってください。

1. XML-RPCが第三者に利用される可能性（赤）

XML-RPCは、外部のアプリからWordPressに投稿するための古い仕組みです。パスワードの総当たり攻撃の入口に使われやすいので、使っていなければ止めます（スマホのアプリやJetpackで投稿していなければ、止めて問題ありません）。

確実なのは、サイトのルートの.htaccessで、xmlrpc.phpへのアクセスを拒否する方法です。# BEGIN WordPress〜# END WordPressの外に書きます（この間はWordPressが書き換えることがあるため）。

<Files xmlrpc.php>
  Require all denied
</Files>

あわせて、テーマ側でXML-RPCの存在を知らせるヘッダーやリンクも消しておきました。

// XML-RPC の場所を知らせる RSD リンクと X-Pingback ヘッダーを出さない
remove_action( 'wp_head', 'rsd_link' );
add_filter( 'wp_headers', function ( $headers ) {
	unset( $headers['X-Pingback'] );
	return $headers;
} );

2. RSSフィードにWordPressのユーザー名が公開されている（黄）

4件の中で、いちばん先に直したいのはこれです。 ログインに使うユーザー名が外から見えると、1の総当たり攻撃が一気にやりやすくなるからです。

原因は、投稿者の「ブログ上の表示名」がログイン名のままになっていたことでした。管理画面の「ユーザー」で、ニックネームと表示名をログイン名とは別のもの（会社名など）に変えます。

さらに、ユーザー名（正確には「スラッグ」）はRSS以外からも読めることがあるので、テーマ側で次の経路も塞ぎました。

// 未ログインのときは、REST API のユーザー一覧を出さない
add_filter( 'rest_endpoints', function ( $endpoints ) {
	if ( ! is_user_logged_in() ) {
		unset( $endpoints['/wp/v2/users'], $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
	}
	return $endpoints;
} );

// 投稿者アーカイブ（/?author=1 など）はトップへ転送する
// 優先度1にするのは、WordPress 標準の転送（/author/ユーザー名/ へ飛ばす）より先に動かすため
add_action( 'template_redirect', function () {
	if ( is_author() ) {
		wp_safe_redirect( home_url( '/' ), 301 );
		exit;
	}
}, 1 );

塞げたかどうかは、次のコマンドで確かめられます（example.comは自分のドメインに置き換えます）。

curl -s "https://example.com/feed/" | grep -o "<dc:creator>.*</dc:creator>" | sort -u
curl -s "https://example.com/wp-json/wp/v2/users" | head -c 60; echo
curl -s "https://example.com/?rest_route=/wp/v2/users" | head -c 60; echo
curl -sI "https://example.com/?author=1" | grep -i "^location"
curl -sI "https://example.com/wp-sitemap-users-1.xml" | head -1

zshでは、コマンドの後ろに# コメントを付けて貼り付けるとエラーになります。上のように、コマンドと期待する結果を分けて書いておくと安全です。

3. ログインページが第三者に特定される可能性（赤）

このサイトは、すでにSiteGuardでログインページのURLを変えていました。それでも特定できると指摘されたものです。

外からたどれる経路（/wp-admin/へのアクセスでログインページに飛ばされないか、/loginや/adminで案内されないか、ページのHTMLにログインURLが含まれていないか）を調べたところ、いずれも漏れていませんでした。診断のあとにプラグインを一斉に更新しているので、その時点で塞がった可能性があります。

ただ、ログインURLを隠すのは補助的な対策です。主な守りは、SiteGuardの画像認証とログインの試行回数の制限（ログインロック）で、こちらが有効になっていることを確認しました。社内からしかログインしないなら、管理画面へのアクセスをIPアドレスで制限するのも効果的です。

4. readme.htmlが閲覧できる（黄など）

WordPressに付いてくるreadme.htmlから、WordPressを使っていることやバージョンが推測できる、という指摘です。readme.htmlはWordPressを更新すると再生成されるので、ファイルを消すのではなく.htaccessで拒否します。

<FilesMatch "^(readme\.html|license\.txt|wp-config-sample\.php)$">
  Require all denied
</FilesMatch>

あわせて、HTMLの<head>とRSSに出るWordPressのバージョン表記も消しました。

remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );

SEOプラグインのAll in One SEOも<head>にバージョンを出します。これはaioseo_hide_generator_tagフィルターで消せますが、古いバージョンのAIOSEOにはこのフィルターがなく、更新したら効くようになりました。

5. wp-cron.phpに外部からアクセスできる → あえて対応しない

wp-cron.phpは、WordPressの予約投稿やプラグインの定期処理を動かすための仕組みです。外部から大量に呼ばれると負荷になる、という指摘ですが、単純に塞ぐと、予約投稿や自動更新が止まります。

塞ぐなら、先にwp-config.phpでDISABLE_WP_CRONを有効にし、サーバーのcronからwp-cron.phpをPHPで直接実行するように切り替える必要があります。そこまでの影響と手間を比べて、今回は意図的に見送りました。

6. メディアファイルが第三者に特定される可能性（黄）

アップロードした画像などの一覧が外からたどれる、という指摘です。コーポレートサイトの画像は公開が前提なので、原則として対応は不要と判断しました。

ただし、旧サイトから移行した古いファイルに、個人情報を含むもの（応募書類や見積書のPDFなど）が混ざっていないかは確認しました。メディアライブラリを月ごとに絞り込んで、目で見て確かめるだけで済みます。

再診断の結果

対応後に手動で再診断したところ、指摘は6件から3件に減りました。XML-RPC、ログインページ、readme.htmlの3件は消えています。

残った3件と、それぞれの判断は次のとおりです。

RSSの指摘は、表示名を変えても消えない

意外だったのがRSSの指摘です。診断ツールは、RSSの投稿者欄（<dc:creator>）に入っている文字を、そのまま「ユーザー名」として拾っているようです。表示名をログイン名と別のものに変えても、変えたあとの表示名が検知されるだけで、指摘自体は残ります。

つまり、この指摘が出たときに確かめるべきなのは「検知された名前がログイン名と同じかどうか」です。

• ログイン名と同じなら：本当に漏れています。表示名を変え、2で紹介した経路も塞ぎます
• ログイン名と違うなら：表示名を拾っているだけなので、安全面では対応済みです

指摘を表示の上でも消したい場合は、RSSの投稿者欄を空にする方法があります。

add_filter( 'the_author', function ( $name ) {
	return is_feed() ? '' : $name;
} );

ただ、これで診断から消えるかは試していません。このサイトはすでにログイン名が外から見えない状態なので、今回はこのままにしました。

残った指摘は「対応漏れ」ではなく、影響を確認したうえで残したものです。 依頼主に報告するときも、理由と一緒に伝えておけば、次回の診断で同じ指摘が出ても不安にさせずに済みます。

対応して気づいたこと

• メールの「今すぐ対策が必要」は強めの表現。中身を見て、優先順位を付けて対応すればよい
• 指摘を機械的にすべて消そうとしない。wp-cron.phpのように、塞ぐと別の機能が止まるものもある
• 対応したら、curlで外から見た状態を確かめ、記録に残す
• プラグインを一斉に更新するなら、先にバックアップを取り、更新後にフォームの送信やタイトル・説明文が変わっていないかを確認する
• 守りを固めるついでに WAF をすべて ON にしたら、記事を更新できなくなった。原因と設定の決め方は エックスサーバーの WAF で更新が 501 になったとき にまとめた

これからサーバーを選ぶなら

法人のサイトで、追加料金なしで毎日の脆弱性診断まで付けたいなら、XServerビジネスはスタンダードから対象になります。今回診断したサイトもXServerビジネスのスタンダードです。

個人向けのエックスサーバーで無料の診断を使いたい場合は、プレミアムプラン以上が対象です（スタンダードは対象外）。