X-XSS-Protectionは「死んだ遺産」だ：現代のWebアプリを守るための現実解
現場でコードレビューをしていると、未だにレガシーな設定を「お守り」のように入れているエンジニアに出会う。その筆頭が X-XSS-Protection ヘッダーだ。
「とりあえずこれを入れとけば安心だろう」という考えは捨ててくれ。結論から言うと、このヘッダーは現代のブラウザでは既に廃止されているか、あるいは攻撃者の踏み台になり得るリスクを孕んでいる。
なぜ今、我々はこれに頼るべきではないのか。そして、代わりとなる本質的な「CSP（Content Security Policy）」の実装戦略とは何か。現場の知見を交えて解説する。
—
1. なぜ「X-XSS-Protection」はゴミ箱行きなのか
X-XSS-Protection は、IE8時代に登場した「反射型XSSをブラウザ側で検知してブロックする」ための簡易的な機能だ。しかし、この仕組みには致命的な欠陥が2つある。
1. 回避と逆利用: 攻撃者はこのフィルターの挙動を熟知している。特定の細工をすることで、逆に「このページは安全だ」というブラウザの判定を狂わせ、本来ならブロックされるはずのスクリプトを強制的に実行させる手法さえ存在する。
2. ブラウザ間の不統一: ブラウザによって挙動が異なり、テストが困難だ。近年のChromeやEdge、Safariは、このヘッダーを完全に無視するか、あるいは不完全な挙動によりセキュリティを低下させるため、主要なブラウザベンダーは「使用を非推奨」とし、CSPへの移行を強く求めている。
教訓: 「古き良き」セキュリティ対策が、現代では「脆弱性の入り口」になる。このヘッダーを削除し、CSPという現代の防壁を構築する準備をしよう。
—
2. 現代の防御戦略：CSP（Content Security Policy）への移行
CSPは、「どこのスクリプトなら実行を許可するか」をホワイトリスト形式でブラウザに伝える強力な仕組みだ。XSSの根本解決（入力値の無害化）を前提としつつ、万が一の脆弱性混入時に、攻撃者が外部へデータを送信したり、不正なスクリプトを読み込んだりするのを防ぐ。
実践：NginxによるCSP設定（本番環境のベース）
まずは、Webサーバーレベルで最低限守るべきポリシーを設定する。これを各プロジェクトのベースラインとしてほしい。
Nginx設定ファイル (nginx.conf / sites-available)
CSPヘッダーの定義
default-src ‘self’: 自分のドメインからのみ許可
script-src ‘self’: インラインスクリプトやevalを禁止し、ソース元を自身のドメインに限定
object-src ‘none’: プラグイン（Flashなど）の実行を完全に拒否
frame-ancestors ‘none’: クリックジャッキング対策（自身のサイトをiframeで埋め込ませない）
add_header Content-Security-Policy “default-src ‘self’; script-src ‘self’; object-src ‘none’; frame-ancestors ‘none’; base-uri ‘self’;” always;
古いブラウザ用の対策を消す（もし残っていれば削除）
more_set_headers -s ‘X-XSS-Protection: 0’;
—
3. アプリケーションコードでの防御（PHPの例）
ヘッダーだけでは不十分だ。アプリケーション層では、ユーザーからの入力を受け取った瞬間に「無害化」する原則を徹底する。
PHPでHTMLを出力する際は、必ず htmlspecialchars を使用する。これは基本中の基本だが、フラグを忘れるケースが多い。
/
function escape_html($str) {
return htmlspecialchars($str, ENT_QUOTES | ENT_HTML5, ‘UTF-8’);
}
// 悪い例： がそのまま実行される
// echo $_GET[‘user_input’];
// 良い例：HTMLエンティティに変換され、ただの文字列として表示される
echo escape_html($_GET[‘user_input’]);
?>
—
4. 現場で「一番刺さる」アドバイス
CSPを導入する際、最も多い失敗は「いきなり厳しくしてサイトの機能が死ぬこと」だ。以下のステップで進めるのが、インシデントを起こさないプロのやり方だ。
1. Report-Onlyモードで監視する:
Content-Security-Policy-Report-Only ヘッダーを使い、ブロックはせずに違反ログだけを収集する。これで、現在のアプリで「何がCSPに抵触しているか」を洗い出す。
2. サードパーティスクリプトの棚卸し:
Google Analyticsや広告タグなど、外部ドメインのスクリプトをどこまで許可するか決める。安易に unsafe-inline を許可してはいけない。
3. Nonce（ナンス）の活用:
どうしてもインラインスクリプトが必要な場合は、リクエストごとに生成するランダムなトークン（Nonce）を付与し、許可されたスクリプトのみを実行させる手法を導入する。
—
まとめ
セキュリティは「設定して終わり」の静的なものではない。ブラウザの仕様変更や攻撃手法の進化に合わせて、我々エンジニアも脱皮し続ける必要がある。
X-XSS-Protection を削除し、CSPを導入する。この小さな変更が、将来の重大なXSSインシデントを防ぐ決定打になる。今日、自分のシステムのレスポンスヘッダーを確認してほしい。そこに「不要な遺産」が残っていないことを祈る。
何か不明点があれば、またいつでも聞いてくれ。現場からは以上だ。
コメント