X-XSS-Protection は「ブラウザ側の簡易XSSフィルターのスイッチ」
まず、X-XSS-Protection をざっくり一言でいうと、
「ブラウザに備わっている“簡易的なXSSフィルター”をどう動かすかを指示するためのレスポンスヘッダ」
です。
ブラウザ（特に古めの IE や一部の旧ブラウザ）には、
「明らかに怪しいスクリプトがページに混ざっていたら、勝手にブロックしたり書き換えたりする」
という“お節介な防御機能”が入っていました。
X-XSS-Protection は、その機能に対して、
有効にするのか
無効にするのか
検出したときにどう振る舞うのか
を指定するための設定です。
WordPress そのものの機能というより、
「サーバーがブラウザに対して出すヒント」の一種だと捉えると分かりやすいです。
そもそもXSSって何？ というところから整理する
XSS（クロスサイトスクリプティング）のざっくりイメージ
XSSは、ざっくり言うと、
本来はただのテキストとして扱うべき“ユーザー入力”が
HTMLやJavaScriptとしてそのままページに混ざってしまい
結果として、攻撃者のスクリプトがユーザーのブラウザで実行されてしまう
という攻撃です。
例えば、コメント欄にこんなものを書かれたとします。
<script>alert('あなたのクッキーを盗みます');</script>
これをそのまま画面に出してしまうと、
ページを開いた人のブラウザでこのスクリプトが実行されてしまいます。
もっと悪い例だと、
クッキーを盗む
偽のログインフォームを表示する
別サイトに勝手にリダイレクトする
といったこともできます。
本来は、
サーバー側でエスケープする
テンプレート側でサニタイズする
などの「アプリケーション側の対策」が主役です。
X-XSS-Protection は、それに加えて「ブラウザ側での簡易防御」をどう扱うか、という話になります。
X-XSS-Protection がやっていること
ブラウザの“組み込みXSSフィルター”への指示
古いブラウザ（特に Internet Explorer 系）には、
「URLやフォーム入力の中に含まれるスクリプトが、そのままページに反映されていないか」
をざっくりチェックして、
怪しければそれをブロックする、という機能がありました。
X-XSS-Protection ヘッダは、例えばこんな値を取ります。
X-XSS-Protection: 0
→ ブラウザのXSSフィルターを無効化
X-XSS-Protection: 1
→ フィルターを有効化（怪しいスクリプトを検出したら“サニタイズ”して表示）
X-XSS-Protection: 1; mode=block
→ フィルターを有効化し、怪しいものを検出したらページの表示自体をブロック
イメージとしては、
「怪しいスクリプトを見つけたら、どうするか？」
をブラウザに伝えるためのフラグです。
重要ポイント：今のブラウザでは“主役”ではない
近年のブラウザは X-XSS-Protection をほぼ無視している
ここがとても大事なポイントです。
Chrome
Firefox
Edge（Chromium版）
といった、現在主流のブラウザは、
X-XSS-Protection を基本的に使っていません
（ヘッダを送っても、ほぼ無視されます）
理由はシンプルで、
この“簡易XSSフィルター”は誤検知も多く
場合によっては逆に攻撃に悪用される可能性も指摘された
ためです。
そのため、モダンブラウザは、
X-XSS-Protection に頼るのではなく
コンテンツセキュリティポリシー（CSP）など、より強力で設計的な対策を推奨する方向に移行しています。
それでも「古いブラウザ向けの補助輪」としては意味がある
とはいえ、完全に無意味かというと、そうでもありません。
古い IE や一部のレガシーブラウザでは、
今でも X-XSS-Protection が効くことがあります。
そのため、
「最新ブラウザではCSPなどを使いつつ、古いブラウザ向けにX-XSS-Protectionも一応設定しておく」
というスタンスは、まだギリギリ“あり”です。
ただし、ここで重要なのは、
X-XSS-Protection を「XSS対策のメイン」として考えないこと
あくまで“補助輪”程度の位置づけにとどめること
です。
例題：X-XSS-Protection が効く／効かないイメージ
例1：古いブラウザでの簡易防御
例えば、古い IE を使っているユーザーが、
URLにこんなクエリを付けてアクセスしたとします。
https://example.com/?q=<script>alert('XSS');</script>
もしアプリ側の実装が甘くて、
この q の値をそのままページに出してしまっていたとします。
X-XSS-Protection が有効なブラウザでは、
「URLの中のスクリプトが、そのままページに出てきている。これは怪しい」
と判断して、
スクリプト部分を無効化したり
場合によってはページの表示自体をブロックしたり
することがあります。
これは、
アプリ側のバグ（XSS脆弱性）を
ブラウザ側が“たまたま”カバーしてくれた
という状態です。
例2：モダンブラウザではそもそも無視される
同じ状況で、Chrome や最新の Edge ではどうかというと、
X-XSS-Protection ヘッダは基本的に無視
＝ブラウザ側の簡易フィルターは働かない
という挙動になります。
この場合、
アプリ側でちゃんとエスケープしていない限り
XSS は普通に成立してしまいます。
ここから分かるのは、
「X-XSS-Protection に頼ってXSSを防ぐ」という発想は、
今の時代には通用しない
ということです。
WordPress と X-XSS-Protection の関係を整理する
WordPress 自体は、ある程度XSS対策を持っている
WordPress コアは、
テンプレートタグでのエスケープ関数（esc_html, esc_attr など）
コメントや投稿のフィルタリング
といった仕組みで、ある程度XSSを防ぐ設計になっています。
ただし、
テーマやプラグインが独自に出力する部分
カスタムコードで直接 echo している部分
などで、エスケープを忘れると、
普通にXSS脆弱性が入り込みます。
ここを守るのは、
X-XSS-Protection ではなく
「ちゃんとエスケープする」「信頼できない入力をそのまま出さない」
という、アプリケーション側の作法です。
X-XSS-Protection は「おまけ」でしかない
WordPress サイトに X-XSS-Protection を設定すること自体は、
技術的には難しくありません。
サーバー設定や .htaccess で、
X-XSS-Protection: 1; mode=block
のようなヘッダを付けるだけです。
ただし、それによって得られる安全性は、
「古いブラウザで、たまたま一部のXSSを防いでくれるかもしれない」
程度のものです。
本当に大事なのは、
テーマ・プラグイン・カスタムコードで
出力時のエスケープを徹底すること
入力値のバリデーションとサニタイズを行うこと
であり、
X-XSS-Protection はそれを補う“薄い保険”くらいに考えるのが現実的です。
プログラミングの感覚で捉える「X-XSS-Protection 設定」
これは「ブラウザの古い安全機能のオンオフを決めるフラグ」
エンジニア目線で言うと、X-XSS-Protection は、
「ブラウザに昔から付いている、簡易XSS検出ロジックをどう扱うか」
を決めるフラグです。
しかし、そのロジックは、
実装がブラウザ依存でブラックボックス
誤検知・過検知の可能性もある
モダンブラウザでは非推奨・無効化の方向
という性質を持っています。
だからこそ、
これにセキュリティを“丸投げ”するのは危険
あくまで「効けばラッキー」くらいの位置づけ
として扱うべきです。
本命は「CSP＋正しいエスケープ」
今のWebセキュリティの文脈では、
XSS対策の本命は
アプリ側のエスケープ・サニタイズ
コンテンツセキュリティポリシー（CSP）
です。
CSP を使うと、
このページでは、インラインスクリプトは禁止
スクリプトはこのドメインからしか読み込んではいけない
といった「ホワイトリスト型」の制御ができます。
X-XSS-Protection は、
そういった“設計された防御”に比べると、
かなり古くて粗い仕組みだ、という理解を持っておくとよいです。
まとめ：X-XSS-Protection 設定は「古いブラウザ向けの薄い保険」くらいに捉える
「X-XSS-Protection 設定」というテーマの本質は、
ブラウザに備わっている簡易XSSフィルターを
有効にするか、無効にするか、どう動かすか
をレスポンスヘッダで指示する、ということです。
ただし、今の時代において押さえておくべきポイントは、
モダンブラウザはほぼこのヘッダを無視している
XSS対策の主役はあくまで「エスケープ」「サニタイズ」「CSP」
X-XSS-Protection は、あってもいいが“頼ってはいけない”レベルの補助輪
という三つです。
もしあなたが「X-XSS-Protection をどう設定しよう？」と悩んでいるなら、
それ自体よりも先に、
自分のテーマやプラグインの出力が、ちゃんと esc_html や esc_attr を通っているか
ユーザー入力をそのままHTMLに差し込んでいないか
をチェックするほうが、セキュリティ的には何倍も効果があります。
X-XSS-Protection は、そのうえで「古いブラウザ向けに一応オンにしておくか」くらいの感覚で触れるのが、エンジニアとして健全な距離感です。
