おい、そこの画面を見せてくれ。
……うん、やっぱりな。お前が先週レビューに出したあのPR、動くには動くが、セキュリティの観点から見ると「時限爆弾」がいくつも仕掛けられているぞ。
「いや、先輩！ちゃんとうちのフレームワークのエスケープ関数通してますよ！」って顔をしているな。だが、フレームワークのデフォルト機能に全幅の信頼を置くのは、暗号理論で言えば「鍵長をケチってMD5でハッシュ化している」ようなものだ。甘い、甘すぎる。
今回は、XSS（クロスサイトスクリプティング）対策の急所である「コンテキスト依存の出力エスケープ」について、現場の泥臭い実態を踏まえて徹底的に叩き込む。教科書に書いてあるような綺麗ごとは抜きだ。攻撃者がどこを狙い、俺たちがどう防ぐべきか、実践コードを交えて解説する。心して聞け。
—
1. なぜ「ただのエスケープ」では防げないのか？
XSS対策の基本として「HTMLエスケープをしなさい」と教わったはずだ。具体的には、特殊文字（ <, >, &, ", ' ）を安全な実体参照（ <, > など）に置き換えるアレだな。
だが、ここで問題だ。
お前は、掲示板の投稿内容をHTMLの「本文」に出力するときだけでなく、JavaScriptの変数に埋め込むときや、HTMLタグの「属性値」に挿入するとき、さらにはCSSのプロパティ値として出力するときにも、全く同じHTMLエスケープだけで済ませていないか？
ここに、多くの開発者がハマる最大の盲点がある。
Webブラウザは非常に「親切（＝お節介）」だ。ブラウザのパーサーは、HTML、CSS、JavaScript、そしてそれらが混ざり合うコンテキストを動的に解釈する。つまり、出力先のコンテキストが変われば、エスケープのルールも完全に変えなければならないということだ。
コンテキストを誤ったエスケープは、セキュリティホールを自ら掘っているのと同義だ。実際の攻撃シナリオを見てみよう。
—
2. 攻撃者が狙う「コンテキストの隙間」とPoC
例として、ユーザーが入力したプロフィール名を、Webページの様々な場所に出力するアプリケーションを想像してほしい。
ケースA：属性値コンテキストでの脆弱性
開発者が「HTMLエスケープしているから大丈夫」と油断して、以下のようなコードを書いたとする。
<!-- 危険な実装例：ダブルクォートで囲まれていない属性値 -->
<input type="text" name="username" value=USER_INPUT>ここに、攻撃者が x id=hacked onclick=alert(document.cookie) という文字列を入力したとしよう。HTMLエスケープ処理によって運悪く（いや、攻撃者にとっては都合よく）スペースやイコールがそのまま通されてしまった場合、生成されるHTMLはこうなる。
<input type="text" name="username" value=x id=hacked onclick=alert(document.cookie)>見事に属性が追加され、ユーザーがその入力欄をクリックした瞬間にセッションハイジャックが成立する。HTMLエスケープだけでは、属性値のクォート省略や、イベントハンドラのインジェクションを防ぎきれない典型例だ。
ケースB：JavaScriptコンテキストでの脆弱性
もっと恐ろしいのは、動的に生成されるJavaScriptの中にユーザー入力を埋め込むケースだ。
<script>
// 危険な実装例：JSの文字列リテラル内にそのまま変数を埋め込む
var userName = "USER_INPUT";
console.log(userName);
</script>ここでユーザーが "; alert(1); // と入力したらどうなるか？
HTMLエスケープ（& や < の置換）を通していたとしても、JavaScriptの文脈ではこれらは特殊文字ではない。結果として生成されるJavaScriptはこうだ。
var userName = ""; alert(1); //";
console.log(userName);はい、ゲームオーバーだ。HTMLエスケープはJavaScriptの文脈では全く無力なのだ。
—
3. 完全防御のための「コンテキスト別」実装ルール
では、どうすればいいのか？
答えはシンプルだ。「出力する場所（コンテキスト）の文法に合わせたエスケープ関数を使い分ける」こと。
俺たちのチームでは、以下のルールを鉄則としている。
1. HTMLボディ（要素の間）: 標準的なHTMLエスケープ（ <, >, &, ", ' を実体参照へ）
2. HTML属性値: 属性値は必ずダブルクォート（"）またはシングルクォート（'）で囲み、かつ属性値用のエスケープ（英数字以外の文字を16進数または10進数の数値実体参照にエンコード）を行う
3. JavaScript変数の埋め込み: 原則としてJS内への動的値の直接埋め込みは禁止。どうしても行う場合は、JSONエンコード（json_encode や json.dumps）を使用し、さらにUnicodeエスケープを徹底する
4. CSSプロパティ値: ユーザー入力をCSSに直接埋め込むことは極力避け、英数字以外の文字をバックスラッシュ記法（\xx）でエスケープする
—
4. 【実務向け】コピペで使えるセキュアな実装サンプル
百聞は一見に如かずだ。PHPをベースにした、コンテキスト別の厳格なエスケープ処理のサンプルコードを示す。現場のコードレビューでそのまま使えるレベルに仕上げてあるので、自分のプロジェクトと見比べてほしい。
PHPによる実装サンプル
<?php
/**
* セキュアな出力エスケープを行うヘルパー関数群
* 開発者は出力コンテキストに応じた関数を必ず選択して使用すること。
*/
/**
* 1. HTMLボディコンテキスト用エスケープ
* 使用場所: <div>USER_INPUT</div> のような要素の間
*/
function e_html(string $str): string {
// ENT_QUOTES: シングルクォートとダブルクォートの両方を変換
// ENT_SUBSTITUTE: 不正なバイトシーケンスを置換して文字化けやパースエラーを防ぐ
// UTF-8: 文字エンコーディングを明示（文字コードの不一致による脆弱性を防ぐ）
return htmlspecialchars($str, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}
/**
* 2. HTML属性値コンテキスト用エスケープ
* 使用場所: <input value="USER_INPUT"> のような属性の中
* ※大前提として属性値は必ずダブルクォート(")で囲むこと
*/
function e_attr(string $str): string {
// htmlspecialcharsは属性値にも有効だが、より厳格に英数字以外の文字を
// 全て数値実体参照（&#xHH;形式）にエンコードする場合は専用のロジックを挟むこともある。
return htmlspecialchars($str, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}
/**
* 3. JavaScript変数コンテキスト用エスケープ
* 使用場所: <script>let name = "USER_INPUT";</script> の中
*/
function e_js(mixed $data): string {
// json_encodeを用いることで、JSとして安全な文字列リテラル（またはオブジェクト）に変換する
// JSON_HEX_TAG, JSON_HEX_AMP, JSON_HEX_APOS, JSON_HEX_QUOT を指定し、
// HTMLパーサーとJSパーサーの解釈の隙をついた攻撃（タグの閉じ込め等）を完全に封じる
$json = json_encode(
$data,
JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT | JSON_UNESCAPED_UNICODE
);
if ($json === false) {
// エンコード失敗時は空文字を返して例外や予期せぬ出力を防ぐ
return '""';
}
return $json;
}
// --- 【使用例】 ---
$userInput = '"><script>alert(1)</script>';
$safeUserName = 'O\'Reilly';
?>
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>コンテキスト別エスケープの実装例</title>
</head>
<body>
<!-- 1. HTMLボディへの出力 -->
<div>
こんにちは、<?= e_html($userInput); ?>さん！
- 出力結果: <script>... と安全に表示される
</div>
<!-- 2. HTML属性値への出力（必ずダブルクォートで囲む） -->
<div>
<input type="text" name="comment" value="<?= e_attr($userInput); ?>">
</div>
<!-- 3. JavaScript変数への出力 -->
<script>
// PHP側でJSONエンコードされた安全なデータを受け取る
// シングルクォートやダブルクォートで囲む必要すらなく、そのまま代入可能
const currentUser = <?= e_js($safeUserName); ?>;
const maliciousInput = <?= e_js($userInput); ?>;
console.log("User:", currentUser);
console.log("Malicious:", maliciousInput); // 安全に文字列として処理される
</script>
</body>
</html>—
5. アプリケーション層だけじゃない！多層防御としてのHTTPヘッダー（CSP）
どんなに優秀なプログラマーでも、人間の手によるコーディングである以上、エスケープの漏れゼロを100%維持し続けるのは難しい。だからこそ、多層防御（Defense in Depth）の思想が必要だ。
アプリケーション層での出力エスケープに加え、Webサーバーやリバースプロキシ（NginxやCloudflareなど）のレベルでContent Security Policy (CSP)を必ず設定しろ。仮にXSSの脆弱性がコード内に混入したとしても、CSPが強力にブラウザのスクリプト実行をブロックしてくれる。
以下に、俺たちが実務で標準採用している堅牢なNginxのCSP設定例を置いておく。
# Nginx セキュリティヘッダー設定例
# 余計なスクリプトの実行や外部からのインジェクションを根絶する
# Content Security Policy (CSP)
# default-src 'self': デフォルトでは同一オリジンからのリソースのみ許可
# script-src 'self': スクリプトは同一オリジンからのみ読み込み（インラインスクリプトの実行を原則禁止）
# object-src 'none': プラグイン（Flash等）の実行を完全に禁止
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; style-src 'self' 'unsafe-inline';" always;
# その他の重要セキュリティヘッダー
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header X-XSS-Protection "0" always;※補足：現代のモダンブラウザでは X-XSS-Protection は無効化（または 0 に設定）し、強力なCSPでコントロールするのがセキュリティ業界のベストプラクティスだ。古いブラウザの不具合を利用したDOM型XSS誘発を防ぐためにも、この設定を推奨する。
—
6. まとめ：プロのエンジニアとしてのプライドを持て
いいか、セキュリティ対策というのは「形だけのルーティンワーク」ではない。攻撃者は常に俺たちのコードの「前提の勘違い」や「たった一箇所のコンテキストの誤り」を血眼になって探している。
今日話した内容をまとめよう。
- 「HTMLエスケープだけしていれば安心」という幻想を今すぐ捨てろ。
- 出力先のコンテキスト（HTMLボディ、属性値、JavaScript、CSS）を正確に把握し、それぞれに最適化されたエスケープ関数を使い分けろ。
- アプリの脆弱性を補う最後の砦として、必ずCSP（コンテンツセキュリティポリシー）をヘッダーに実装しろ。
お前が書くその1行のコードが、会社の信頼を守ることもあれば、一瞬で地獄に落とすこともある。
さあ、自分の書いたコードベースに戻って、もう一度エスケープのコンテキストを見直してみろ。何か見つかったら、すぐに修正PRを上げるんだ。頼んだぞ！
コメント