XSS — 他人のブラウザで悪いスクリプトを動かす攻撃

DOM型XSSは、サーバを介さずブラウザ内だけで完結します。鍵になるのは2つの地点です。

• source（ソース）※1 — 攻撃者が値を注ぎ込める入口。location.hash・location.search・document.referrer・postMessage で受け取ったデータ・localStorage など
• sink（シンク）※2 — その値が「コードとして解釈されうる出口」。innerHTML・outerHTML・document.write・eval・setTimeout（文字列渡し）・setAttribute（href／onclick など）・location への代入

sourceからsinkへ、途中でエスケープされないまま値が流れると発火します。ここで大事なのは、サーバの応答HTMLには危険な文字列が一度も現れないことがあるという点です。

だからサーバ側の出力エスケープだけでは素通りします。防御はsinkの手前、つまりブラウザ内で「HTMLとして解釈させない代入（textContent など）」や「サニタイズ」を置くことになります。反射型・格納型が「サーバの出力の問題」なのに対し、DOM型は「ブラウザ内の出力の問題」——同じXSSでも守る場所が違います。

登場人物メモ：

• ※1 source — 攻撃者が制御できる値の入口（location.hash などブラウザが持つデータ）
• ※2 sink — 値がコードやHTMLとして解釈されうる出口（innerHTML や eval など）

反射型と格納型は「どこを経由して値がHTMLに混ざるか」の違いでした。上級では、その内部差が守り方に効くことを押さえます。

• 反射型 — 値はリクエストごとに一度だけ応答へ反射する。被害は「その細工URLを踏んだ人」に限られ、誘導（フィッシング）が前提になる
• 格納型 — 値がサーバに保存され、閲覧した全員に繰り返し配られる。誘導が要らず、被害範囲が桁違いに広い（ワーム化もありうる）

さらに厄介なのが mutation XSS（mXSS） です。これは、いったん安全に見えた文字列が、ブラウザのHTMLパーサが「見た目を正す」過程で危険なタグに化ける現象です。

• サニタイズ処理は「ある解釈」で無害と判断した
• ところが innerHTML に入れた瞬間、ブラウザが不正なネストや文字を別のツリーに再構築し、無害だったはずの断片が実行可能なタグに変わる
• 教訓は「文字列として安全」と「DOMに入れても安全」は別物、ということ。だから信頼できるサニタイザに任せる

XSS対策の核心は「入力の混入ではなく、出力の文脈で防ぐ」ことでした。上級では、その「文脈」を具体化します。値を出す先ごとに、危険な文字も脱出の仕方も違うからです。

• HTML本文 — < > & を実体参照へ。タグの開始を許さない
• HTML属性 — 属性を囲む引用符と、引用符を省いたときの空白などを無害化。属性の脱出を防ぐ
• JavaScript文字列 — 文字列リテラルを抜ける記号（引用符・バックスラッシュ・改行）を処理。値をコードとして生成しないため、そもそもJSにデータを直書きしない設計が上策
• URL — スキームを検証（javascript: を弾く）し、パーセントエンコード。属性の href／src は要注意
• CSS — スタイル値へ生の入力を入れない。expression 相当や url() 経由の悪用を避ける

自由なHTMLをどうしても許したい（リッチテキストなど）場合は、自作エスケープではなく DOMPurify のような実績あるサニタイザで「許可タグ・属性の許可リスト方式」に通します。ここでmXSSまで面倒を見てくれるのが、既製サニタイザを使う理由です。

なぜ入力側で一律に消さないのか。値は保存や再利用の途中では無害で、危険になるのは「特定の文脈へ出す瞬間」だけだからです。入口で削ると本来正しいデータ（a < b のような文字列）まで壊し、しかも別の出口では守れません。詳しくは 入力バリデーション と Webの中のセキュリティ を参照。

エスケープを人手で完璧に保つのは難しい。そこで破られた前提で実行自体を止めるのが CSP と Trusted Types です。

• CSP（Content Security Policy） — 「どの出所のスクリプトを実行してよいか」をブラウザに宣言する
  • nonce方式 — 応答ごとに使い捨ての乱数を付け、その nonce を持つ <script> だけ実行を許す
  • hash方式 — 許可するインラインスクリプトのハッシュを列挙する
  • strict-dynamic — nonce付きで信頼したスクリプトが動的に読み込む子スクリプトも連鎖的に信頼し、ホスト名の許可リスト管理から解放する
• よくある回避 — unsafe-inline の残置・過度に広い許可ホスト・信頼した出所に置かれた JSONP や古いライブラリの悪用。CSPは補助であって、エスケープの代わりにはならない
• Trusted Types — innerHTML など危険なsinkに生の文字列を渡せなくするブラウザ機構。値は必ず「信頼済み型」を通す必要があり、サニタイズの通し忘れを型で強制できる

CSPが「実行の出所」を絞り、Trusted Typesが「sinkへの入力」を絞る。エスケープ（出口の変換）と合わせて三重に構えるのが上級の守りです。

「危ない語を入口で消せばよい」が効かない理由を、もう一段はっきりさせます。

• 文脈が入口では未定 — 同じ値がHTML本文にも属性にもURLにも出うる。入口では「どの脱出を防げばよいか」が決まらない
• 抜け道が無限 — 大文字小文字・エンコード・全角/半角・コメント挿入・mXSSなど、ブラックリストは必ず抜かれる
• 正当なデータを壊す — <, &, 引用符は普通の文章にも現れる。入口で削ると機能が壊れる

だから入力検証は土台（想定外を弾く入口）に留め、XSSの主対策は出口の文脈別エスケープに置き、CSP／Trusted Types／HttpOnly Cookie で破られたときの被害を抑える。役割分担が答えです。

• DOM型の見落とし — サーバ側だけ守り、innerHTML などブラウザ内のsinkを放置する
• サニタイズ済みの再加工 — 一度浄化した文字列を後段で連結・再パースし、mXSSを招く
• CSPを免罪符にする — unsafe-inline を残す、広すぎるホスト許可、JSONP経由のバイパス
• 文脈の取り違え — HTML用エスケープをJSやURLに流用し、属性やスキームで抜かれる
• テンプレートの自動エスケープ過信 — innerHTML 相当のヘルパや「安全と印を付ける」機能で自動エスケープを外すと穴になる