「X-XSS-Protectionはもう古い」—なぜ今、私たちはCSPへの移行を急ぐべきなのか

現場のエンジニア諸君、お疲れ様。今日もどこかのログで怪しいリクエストと格闘していることだろう。

さて、今回はWebセキュリティの「遺物」となりつつある X-XSS-Protection ヘッダーについて話をしよう。かつては「これさえ付けておけば安心」と言われた魔法の呪文も、現代のブラウザ環境ではむしろ「セキュリティの脆弱性を生む要因」になりかねない。

なぜこのヘッダーが非推奨なのか、そして我々が今すぐ取るべき「次の一手」は何か。現場の血の通った知見を共有する。

—

1. X-XSS-Protectionの正体と「なぜ捨て去るべきか」

X-XSS-Protection は、かつてIEやChromeが独自に実装していた「ブラウザのXSSフィルタ機能」を制御するためのヘッダーだ。1; mode=block と設定すれば、ブラウザが怪しいスクリプトを検知した際にページ描画を強制停止してくれる。

しかし、なぜこれが現代では「悪」なのか？

攻撃者が見ている「盲点」

攻撃者は、このヘッダーが引き起こす「意図しない挙動」を狙う。
1. バイパスの踏み台: ブラウザ側のフィルタは完全ではない。巧妙に細工されたペイロードにより、フィルタを逆に「悪用」して、本来実行されるはずの正常なスクリプトを無効化し、ページを崩壊させるDoS攻撃が可能になる。
2. 情報の漏洩: フィルタが「誤検知（False Positive）」を起こした際、機密情報を含むURL構造を外部に送信してしまうケースが過去に報告されている。

要するに、ブラウザに「余計な気を利かせるな」というのが現代のセキュリティの潮流だ。ブラウザの制御下に置くのではなく、「アプリの設計でXSSを根絶する」。これがプロの姿勢だ。

—

2. 脱・X-XSS-Protection、移行先はCSP一択

今すぐやるべきことは、古いヘッダーを削除し、Content-Security-Policy (CSP) を導入することだ。CSPは、どのドメインからスクリプトを読み込めるかを厳格に定義する「ホワイトリスト方式」のセキュリティモデルである。

実践：Nginxでの設定例

まずは、不要な古いヘッダーを捨て、強力なCSPを構築する設定だ。

Nginx設定ファイルに追加
1. 古いヘッダーを削除
more_clear_headers “X-XSS-Protection”;

2. CSPを厳格に定義
default-src ‘self’: 自分自身からのみ読み込み
script-src ‘self’: 外部からのスクリプト読み込みを禁止（インラインスクリプトもNG）
object-src ‘none’: プラグイン実行を禁止
add_header Content-Security-Policy “default-src ‘self’; script-src ‘self’; object-src ‘none’; frame-ancestors ‘none’; base-uri ‘self’;” always;

3. 念のためX-Content-Type-Optionsも設定（MIMEタイプスニッフィング対策）
add_header X-Content-Type-Options “nosniff” always;

—

3. アプリケーション層での「真の対策」

ヘッダーはあくまで「保険」に過ぎない。本質的な対策は、ユーザーからの入力を信頼せず、適切なエンコーディングを行うことだ。

Python (Flask) でのセキュアな実装例

Flaskは標準でJinja2テンプレートエンジンが自動エスケープを行うが、意図的にそれを無効化するコードを書かないことが鉄則だ。

from flask import Flask, render_template_string, request

app = Flask(__name__)

@app.route(‘/profile’)
def profile():
# ユーザー入力（本来はデータベースから取得）
user_input = request.args.get(‘name’, ‘Guest’)

# 悪い例: テンプレート内で |safe フィルタを使ってはいけない
# return render_template_string(“

Hello, {{ name|safe }}

“, name=user_input)

# 良い例: 自動エスケープに任せる
# これにより、