Trusted Typesの適用とは？require-trusted-types-for 'script'の導入手順と診断基準

Trusted Typesの適用とは

Trusted Typesの適用とは、Content Security Policy（CSP）に require-trusted-types-for 'script' を指定して、DOM XSSの原因となる危険なAPIに、ただの文字列を渡すことをブラウザに禁止させることです。

対象となる危険なAPIは「インジェクションシンク」と呼ばれ、次のようなものがあります。

• innerHTML、outerHTML、insertAdjacentHTML
• document.write
• eval、setTimeout への文字列渡し
• script.src など

CSPに require-trusted-types-for 'script' を指定すると、これらのシンクには、ポリシー関数で検査・無害化した TrustedHTML／TrustedScript／TrustedScriptURL オブジェクトしか渡せなくなり、文字列を渡すと TypeError になります。

Trusted Typesの対応状況と位置づけ

MDNによれば、Trusted Types は2026年2月に Baseline（Newly available）となり、Chrome／Edge に加えて Safari と Firefox でも利用できるようになりました。ただし、既存のJavaScriptライブラリが文字列でシンクを使っていることが多く、導入には段階的な改修が必要です。このためセキュリティAIチェッカーでは、参考項目（low、重み1）として扱います。

Trusted Typesの仕組みとポリシーの書き方

2つのディレクティブ

OWASP WSTG-CONF-12 は、次の点を確認するよう求めています。

• trusted-types だけで require-trusted-types-for がなければ強制されないこと
• trusted-types * や、何でも通す default ポリシーは保護を無効化すること

ポリシーの例

// DOMPurify でサニタイズしてから TrustedHTML にする
const policy = trustedTypes.createPolicy("sanitize", {
  createHTML: (input) => DOMPurify.sanitize(input),
});
element.innerHTML = policy.createHTML(userInput);

default という名前のポリシーを作ると、文字列がシンクに渡されたときに自動で呼ばれます。MDNはこれを既存コード改修中の移行手段として位置づけており、恒久的な解決策ではありません。

Trusted Typesについてよくある誤解

• 「Trusted Typesを入れればXSS対策は完了」：そうではありません。サーバー側テンプレートで生成される反射型・格納型XSS（HTMLインジェクション）は対象外です。WSTGも、根本原因（シンクの使い方）の修正の代替ではないとしています。
• 「innerHTMLを使っていれば必ず脆弱」：これも誤りです。固定文字列や、適切にエスケープした値だけを入れるなら直ちに危険ではありません。Trusted Typesは、それを機械的に保証する手段です。
• 「導入すると非対応ブラウザで表示が壊れる」：非対応ブラウザでは単に無視されるため、表示が壊れることはありません（対応ブラウザで違反があった場合に壊れます）。

JavaScript内の危険なAPIの使用状況そのものは「危険なJavaScript APIの兆候」でも確認します。

Trusted Typesの適用の診断基準（セキュリティAIチェッカー）

取得方法

トップページの最終応答1件について、次の2点を確認します。追加の通信はありません。

1. 強制 Content-Security-Policy レスポンスヘッダーに require-trusted-types-for 'script' があるか。ヘッダーが複数ある（カンマ連結）場合も、いずれかのポリシーにあれば適用ありとします。大文字小文字は区別しません。
2. 取得したHTML本文（インラインscriptを含む）に、innerHTML、outerHTML、insertAdjacentHTML、document.write、eval(（eval と ( の間の空白は許容）のいずれかの文字列があるか（DOM XSSシンクの兆候）。大文字小文字を区別しない単純な文字列一致で、eval( だけは語の先頭から始まる場合に限ります（window.eval( は一致し、retrieval( や _eval( は一致しません）。外部JavaScriptファイルの中身は取得しません。

判定条件

• Report-Onlyヘッダーやmeta要素の require-trusted-types-for は、強制とみなしません。
• trusted-types ディレクティブの許可ポリシー名の妥当性（* や緩い default ポリシー）は評価しません。

得点への影響

総合スコアへの影響は小さく、主に改善の方向性を示すための項目です。

自治体サイトでの判定例

HTML内のコメントや説明文に「innerHTML」という単語があるだけでも兆候として数えるため、△の結果は目視で確認してください。retrieval( のように eval( を末尾に含む別の関数名は兆候に数えません。

Trusted Typesがないとどんなリスクがあるか（DOM XSS）

• 痕跡が残りにくいDOM XSS：DOM XSSは、URLのフラグメント（# 以降）やクエリ、postMessage の値をJavaScriptが innerHTML 等へ渡すことで発生し、サーバーのログに痕跡が残りにくい特徴があります（WSTG-CLNT-01）。
• 自治体サイト特有の入口：検索結果の表示、多言語切替、ふりがな・読み上げ等の補助ツール、地図やイベントカレンダーの埋め込みなど、クライアント側でHTMLを組み立てる機能が多く、DOM XSSの入口になり得ます。
• 攻撃成立時の被害：偽のログイン画面・申請フォームの表示、入力内容の外部送信、サイト内の情報の改ざん表示が可能になります（CWE-79）。
• 抜け漏れを機械的に防げない：Trusted Typesがない場合でも、他の対策（出力エスケープ、CSPの script-src 制限）で防げることはありますが、シンクごとの抜け漏れを機械的に検出・遮断する手段がありません。

Trusted Typesの導入方法（Apache・nginx・IIS・Next.js）

段階1：Report-Onlyで違反箇所を洗い出す

# Apache（.htaccess）
<IfModule mod_headers.c>
  Header always set Content-Security-Policy-Report-Only "require-trusted-types-for 'script'; report-uri /csp-report"
</IfModule>

# nginx
add_header Content-Security-Policy-Report-Only "require-trusted-types-for 'script'; report-uri /csp-report" always;

ブラウザの開発者ツールのコンソールにも違反が表示されます。どのファイルの何行目でシンクに文字列が渡されているかを一覧にします。

段階2：コードを安全なAPIへ置き換える

// 悪い例
el.innerHTML = "<b>" + name + "</b>";
// 良い例（テキストとして表示）
const b = document.createElement("b");
b.textContent = name;
el.replaceChildren(b);

テキスト表示に textContent など安全な描画関数を使うことは、OWASP ASVS 5.0.0 V3.2.2（Level 1）の要件でもあります。HTMLを挿入する必要がある箇所だけ、サニタイズを行うポリシー経由にします。DOMPurify は RETURN_TRUSTED_TYPE: true オプションで TrustedHTML を返せます。

段階3：強制する

Header always set Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'; require-trusted-types-for 'script'; trusted-types sanitize dompurify"

IIS では web.config の customHeaders、Next.js では next.config.js の headers() または proxy.ts（Next.js 15 以前は middleware.ts）で同じ値を設定します。

// next.config.js
module.exports = {
  async headers() {
    return [{ source: "/(.*)", headers: [{ key: "Content-Security-Policy",
      value: "object-src 'none'; base-uri 'self'; require-trusted-types-for 'script'; trusted-types sanitize" }] }];
  },
};

フレームワークやバンドラー（webpack 等）、ライブラリは、独自の名前でポリシーを作ることがあります。trusted-types の許可リストに無い名前は作成時に例外になるため、Report-Only段階でコンソールに出るポリシー名を確認して、許可リストに加えます。

設定後の確認方法

curl -sI https://www.city.example.lg.jp/ | grep -i '^content-security-policy:' | grep -io "require-trusted-types-for[^;,]*"

ブラウザで trustedTypes.createPolicy が使えるか、また開発者ツールに This document requires 'TrustedHTML' assignment のような違反が出ていないかを、主要画面ごとに確認します。

サイトを壊さないための注意点（ガードレール）

• CMSのテンプレート、アクセス解析タグ、広告・翻訳・地図などの外部ウィジェットは、文字列でシンクを使うことが多く、強制すると機能が止まる可能性があります。必ずReport-Onlyの期間を設けてください。
• 何でも通す default ポリシー（入力をそのまま返す）を作ると、強制していても保護効果はほぼなくなります。
• 上位ディレクトリで一括適用すると、配下の全アプリに影響します。対応済みのアプリのディレクトリ単位で導入するのが安全です。
• 本項目は low・重み1の参考項目です。「CSPがレスポンスヘッダーで強制されている」、「CSPの基幹ディレクティブ」、「CSPでunsafe-inlineを許可していない」など、優先度の高い対策を先に行ってください。

よくある質問（FAQ）

参考資料

• MDN Trusted Types API
• W3C Trusted Types 仕様
• OWASP WSTG-CONF-12 Test for Content Security Policy
• OWASP ASVS 5.0.0 V3 Web Frontend Security（V3.2.2・V3.4.3）
• OWASP DOM based XSS Prevention Cheat Sheet
• web.dev「Prevent DOM-based cross-site scripting vulnerabilities with Trusted Types」
• DOMPurify（GitHub）
• Can I use: Trusted Types
• IPA「安全なウェブサイトの作り方」

「Trusted Typesの適用」と関連する診断項目

• 危険なJavaScript APIの兆候high
• CSPがレスポンスヘッダーで強制されているhigh
• CSPの基幹ディレクティブhigh
• CSPでunsafe-inlineを許可していないhigh
• Content Security Policyhigh
• CSPでunsafe-evalを許可していないhigh
• CSPのdefault-srcmedium
• CSPの過剰なワイルドカードhigh