脆弱性の「深淵」を覗く：DOMシンクの汚染と、モダンWebにおけるフロントエンド・アーキテクチャの責務
セキュリティの世界において、「脆弱性は常に最も弱いリンクから侵入する」という言葉は陳腐だが、ことDOMベースのXSS（Cross-Site Scripting）に関しては、その「リンク」がエンジニアの日常的なコーディング習慣の中に埋もれていることに気づく必要がある。
多くの開発者がinnerHTMLを「便利で速い」という理由で採用するが、これはセキュリティの観点から見れば、庭の鍵を泥棒に預けているのと同義だ。今日は、表面的な「XSS対策」の先にある、DOMシンク（Sink）の深層と、堅牢なフロントエンド・アーキテクチャの構築論について語ろう。
—
1. 危険な「シンク」の正体：なぜ innerHTML は悪魔の囁きなのか
DOM-based XSSの根本原因は、「汚染されたソース（Source）」から「危険なシンク（Sink）」へのデータフローを、ブラウザのパーサーが適切に制御できないことにある。
innerHTMLやdocument.write()は、文字列を直接HTMLパーサーに放り込む。この時、ブラウザは文字列内に紛れ込んだ
特筆すべきは、これがサーバーサイドのパケットを介さず、クライアントサイドのメモリ内だけで完結する点だ。IPSやWAFがいくらパケットのヘッダーを検査しても、この攻撃を防ぐことはできない。なぜなら、攻撃対象はサーバーではなく、ユーザーのブラウザという「閉じられた実行環境」の内部メモリだからだ。
—
2. 安全な代替APIへの転換：アーキテクチャの標準化
我々が現場で徹底すべきは、「DOM操作の抽象化と厳格な型付け」だ。textContentやinnerTextへの移行は単なるコード修正ではなく、UI構築のプロトコルを「解析可能なデータ」へと変えるパラダイムシフトである。
セキュアなDOM操作のベストプラクティス例
// 【NG】危険なシンクによるHTML挿入
const container = document.getElementById(‘user-profile’);
container.innerHTML = userInput; // 攻撃者がここで任意のスクリプトを注入可能
// 【OK】安全なDOM操作（textContentによるテキストノード化）
// ブラウザはこれをHTMLとして解釈せず、純粋な「文字列」として描画する
const container = document.getElementById(‘user-profile’);
container.textContent = userInput;
// より高度なケース：安全なDOM要素生成
const createSafeElement = (tag, content) => {
const el = document.createElement(tag);
el.textContent = content; // 型安全性とDOMの分離を保証
return el;
};
もし、どうしてもHTMLを描画する必要があるならば、DOMPurifyのような信頼性の高いライブラリを用いたサニタイズを必須とする。だが、最も安全なのは「HTMLを文字列として扱わない」アーキテクチャだ。
—
3. 次世代の防衛層：CSPとTrusted Types
現代の堅牢なフロントエンドは、コードの書き方だけに依存しない。「ブラウザの実行ポリシー」を強制するアーキテクチャこそが、最高峰の防衛策だ。
Trusted Typesの強制
Trusted Typesは、危険なシンクへのデータ入力を「型」で縛る仕組みだ。これにより、文字列をそのままシンクに渡そうとすると、ブラウザがランタイムエラーを発生させ、攻撃を未然に阻止する。
// Trusted Typesの設定例（CSPヘッダーで配信する）
// Content-Security-Policy: require-trusted-types-for ‘script’;
const policy = trustedTypes.createPolicy(‘my-policy’, {
createHTML: (input) => DOMPurify.sanitize(input) // 厳格なポリシーを通したものだけを許可
});
// シンクには「信頼されたオブジェクト」のみが渡される
element.innerHTML = policy.createHTML(userInput);
—
4. プロンプトインジェクションとの交差点
現在のセキュリティエンジニアが直面している最大の難問は、生成AIとの統合だ。LLMが生成したコンテンツをそのままフロントエンドのUIに流し込む際、それは「プロンプトインジェクション」と「XSS」の複合体となる。
LLMの出力にHTMLタグが含まれていた場合、それをそのままinnerHTMLで描画することは、自ら攻撃の入り口を生成する行為に等しい。AI時代のフロントエンド開発において、「LLMの出力はすべてUntrusted（信頼できない）」というゼロトラストの原則を、DOM操作のレベルまで徹底しなければならない。
—
チーフホワイトハッカーからの提言
セキュリティは「ツール」ではなく「規律」だ。どれほど高度な耐量子暗号を導入しても、あるいは最新のWAFを構築しても、開発者がinnerHTMLという名のショートカットを選択し続ける限り、システムは脆弱であり続ける。
コードレビューの際は、単にバグを探すのではなく、「データがソースからシンクへ到達するまでの、暗黙的な暗黙的な型変換が行われていないか」を追跡してほしい。その泥臭い追跡の積み重ねこそが、アーキテクチャの強靭さを生む。
我々の仕事は、壊れないシステムを作ることではない。壊れることを前提に、その被害範囲を最小化し、攻撃者に「割に合わない」と思わせる構造を作ることだ。今日から、君のレポジトリ内の innerHTML をすべて検索し、書き換えることから始めてくれ。それが、プロのエンジニアが取るべき最初の一歩だ。
コメント