Trusted TypesによるDOM-based XSSの構造的防止

エスケープやサニタイズによる DOM-based XSS 対策は、突き詰めると「危険な API を呼ぶ前に必ず無害化を挟む」という規律に依存します。問題は、その規律が1か所でも破られれば破綻することです。Trusted Types は、危険なシンクが生の文字列を物理的に受け付けないようブラウザ側で強制し、この「うっかり」をプラットフォームレベルで排除します。ここでは型による遮断の原理と、既存コードへの段階導入を整理します。

何を型で禁止するのか

Trusted Types が守るのは injection sink と呼ばれる一群の DOM API です。これらは渡された文字列をコード・マークアップ・スクリプト URL として解釈する性質を持ちます。

require-trusted-types-for 'script' が有効なドキュメントでは、これらシンクへ普通の文字列を代入した瞬間に TypeError が投げられ、代入自体が起きません。通せるのは対応する Trusted 型のオブジェクトだけです。重要なのは、これらの型がコンストラクタを公開していない点です。new TrustedHTML() はできず、唯一の生成経路は登録済みポリシー関数の呼び出しに限られます。型システムが「無害化を経由したことの証明書」として機能する、というのが設計の核心です。

ポリシー — 型の唯一の生成口

ポリシーは trustedTypes.createPolicy で作る、変換関数の名前付きの束です。createHTML／createScript／createScriptURL の3つを必要なぶんだけ実装します。

const policy = trustedTypes.createPolicy('app-html', {
  createHTML: (input) => DOMPurify.sanitize(input),   // 浄化してから型を発行
  createScriptURL: (url) => {
    const u = new URL(url, location.origin);
    if (u.origin !== location.origin) throw new TypeError('cross-origin script');
    return u.href;                                     // 同一オリジンのみ許可
  },
});

el.innerHTML = policy.createHTML(richText);  // TrustedHTML が返り、代入が通る
el.innerHTML = richText;                     // 生文字列 → TypeError

policy.createHTML(s) は内部で変換関数を呼び、その戻り値の文字列を TrustedHTML でラップして返します。つまり変換関数自体はただの文字列を返せばよく、ラップはブラウザが行います。ここで DOMPurify.sanitize のような浄化を呼ぶことで、「型を得るには必ず浄化を通る」という不変条件が成立します。変換関数が浄化をサボれば穴になりますが、そのコードはポリシー定義というただ一点に集約されるため、アプリ全体に散らばった無数のシンク呼び出しではなく、この関数だけを監査すればよくなります。これが Trusted Types の費用対効果の源泉です。

CSP による配信とポリシー名の制限

Trusted Types は独立した API ではなく、CSP のディレクティブとして配信・強制されます。2つのディレクティブが役割を分担します。

Content-Security-Policy:
  require-trusted-types-for 'script';
  trusted-types app-html app-url 'allow-duplicates'

require-trusted-types-for 'script' がシンクの強制スイッチで、これが無ければ Trusted Types API は使えても遮断は起きません。trusted-types ディレクティブは使ってよいポリシー名のホワイトリストで、ここに無い名前で createPolicy を呼ぶと例外になります。これにより、注入された攻撃コードが勝手に createPolicy('evil', { createHTML: s => s }) で恒等ポリシーを作って遮断を骨抜きにする、という攻撃を防ぎます。同名ポリシーの重複登録は既定で禁止（2回目で例外）で、許す場合のみ 'allow-duplicates' を付けます。trusted-types 'none' と書けば、いかなるポリシー生成も禁止できます。

評価の土台となる CSP のディレクティブ照合とフォールバック規則は Content Security Policyの内部動作と回避耐性 を参照してください。Trusted Types はスクリプトの実行を縛る script-src とは独立に、危険なシンクへの到達を縛る相補的な層です。

default ポリシーと暗黙の文字列代入

実コードでは、自分が直接書いていない箇所——サードパーティ製ライブラリやフレームワーク内部——がシンクへ文字列を渡すことが避けられません。これらをすべて書き換えるのは非現実的です。そこで default という特別な名前のポリシーが用意されています。

trustedTypes.createPolicy('default', {
  createHTML: (input, type, sink) => {
    // type には 'TrustedHTML'、sink には 'Element innerHTML' などが渡る
    return DOMPurify.sanitize(input);
  },
});

default ポリシーを定義すると、Trusted 型が要求される箇所に生文字列が渡されたとき、例外を投げる代わりにブラウザが自動でこの default.createHTML を呼び、その結果を使います。コールバックには入力文字列のほか、要求される型名（'TrustedHTML' など）とシンク名（'Element innerHTML' など）が渡るので、どの呼び出し元かを判別してログや個別処理ができます。これにより、改変できない既存コードを一括で救済できます。

段階導入 — Report-Only から enforce へ

いきなり強制すると、生文字列をシンクへ渡している既存箇所がすべて TypeError で止まり、ページが壊れます。そこで CSP と同じく Report-Only から始めるのが定石です。

Report-Only モードでは、シンクへの生文字列代入はそのまま実行されつつ違反レポートだけが送られます。report-to で指定したエンドポイントに、どのシンクでどのファイル・行から違反が起きたかが届くため、アプリ中の Trusted Types 非対応箇所を網羅的に棚卸しできます。レポートを潰し切ってから enforce ヘッダへ切り替えれば、ユーザー影響なしに移行できます。

// 違反レポートの受信（Reporting API 経由、report-to で配信先を宣言）
// 各レポートに sink 名・blockedURL・sourceFile・lineNumber が含まれる

限界と多層防御での位置づけ

Trusted Types はブラウザ実装に依存します。未対応ブラウザでは API も強制も無視されるため、Trusted Types を「唯一の対策」にはできません。あくまで、対応ブラウザでサニタイズ漏れを構造的に不可能にする緩和層です。