【実務・中級編】XSS対策としてのコンテキスト依存の出力エンコーディング – アプリケーションセキュリティ & 安全な開発防御ガイド

XSSは「教科書通りのエスケープ」で防げるか？現場で語られるべき防御の真実

「エスケープ処理は実装しているのに、なぜかXSS（クロスサイトスクリプティング）が抜けてくる」。
現場で疲弊したエンジニアから、そんな嘆きを何度聞いたことか。

多くの開発者は、htmlspecialchars()を呼べば「XSSは卒業」だと思い込んでいる。しかし、それは大きな間違いだ。攻撃者は、君たちが適当に埋め込んだ変数が、HTMLのどの「文脈（Context）」に流し込まれているかを冷静に見ている。

今日は、小手先の対策で満足している君たちのために、「コンテキスト依存の出力エンコーディング」という、セキュリティの現場における最低限にして最強の作法を叩き込む。

—

1. なぜ「汎用的なエスケープ」だけでは死ぬのか

XSSの正体は、ブラウザが「これはデータだ」と期待していた場所に、攻撃者が「これは命令（JavaScript）だ」と誤認させるコードを注入することにある。

例えば、以下のコードを見てほしい。

htmlspecialchars() を使って < や > をエスケープしたとしても、"（ダブルクォート）を適切に処理しなければ、属性値から脱出して別の属性を注入されてしまう。これがコンテキストを無視した対策の末路だ。

---

2. コンテキスト別・鉄壁の防御ルール

出力先によって、取るべき対策は明確に決まっている。以下のルールを脳に刻め。

A. HTMLタグ内（テキストコンテンツとして表示）

や

の中身など。ここでは < > & " ' をエスケープすれば安全だ。

B. HTML属性値（valueなど）

必ずダブルクォート（"）で囲み、かつ属性値として適切なエスケープを行うこと。

C. JavaScript内（動的な値の埋め込み）

これが最も危険だ。JSの変数の値としてJSONを渡す際は、HTMLエスケープではなく、Unicodeエスケープが必要になる。

---

3. 実践：コピペで使えるセキュアな実装コード

理屈はいい、現場で動くコードだ。

PHPの場合：安全なレンダリング

PHPであれば、標準関数をラップした関数を自作するか、テンプレートエンジン（Twigなど）に任せるのが定石だ。

HTML属性として安全に出力するためのヘルパー

/
function h_attr($str) {
// ENT_QUOTES | ENT_HTML5 でシングル/ダブルクォートを確実に処理
return htmlspecialchars($str, ENT_QUOTES | ENT_HTML5, 'UTF-8');
}

// 利用例：HTML属性の中
echo '';

JavaScriptの場合：JSONエンコードの罠を回避

JSの中に値を埋め込むとき、最もやってはいけないのが「テンプレートリテラルでそのまま突っ込む」ことだ。必ずjson_encodeを通した上で、HTMLタグを含まない形式で出力せよ。

// PHPサーバーサイド

---

4. 最後の砦：Content Security Policy (CSP)

どれだけ注意深くコードを書いても、ヒューマンエラーはゼロにはならない。そこで、ブラウザ側で実行を制限する「CSP」というインフラ設定を導入する。

NginxやWebサーバーのレスポンスヘッダーに以下を追加せよ。

Nginx設定例
インラインスクリプトを禁止し、信頼されたソースからのみスクリプトを読み込む
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.cdn.com; object-src 'none';";

これを入れておくだけで、仮にXSSの脆弱性が残っていたとしても、攻撃者が仕込んだインラインの