Trusted Types 详解：彻底防御 innerHTML XSS 漏洞

Trusted Types 并非万能的 XSS“净化器”，而是一种通过强制策略封装来阻断未受控 innerHTML 等高危 DOM 操作的运行时防护机制——它只有在正确配置 CSP 响应头（require-trusted-types-for + trusted-types）、策略提前加载且全覆盖所有 sink（如 outerHTML、insertAdjacentHTML、document.write 等）、且策略本身不越界执行过滤或动态代码的前提下，才能真正发挥效力；实践中应优先用 textContent 或预编译模板规避风险，将 Trusted Types 视为最后一道防线而非替代安全编码习惯的捷径。

Trusted Types 不能“彻底消除” innerHTML 引起的原始 XSS 漏洞，但它能强制阻断所有未经策略封装的字符串赋值行为——前提是 CSP 头正确启用、策略覆盖到位、且无间接调用逃逸。

必须配对 CSP 响应头才能生效

仅在 JS 中调用 trustedTypes.createPolicy() 完全不产生防护效果。浏览器只在收到以下 HTTP 响应头后才开启运行时拦截：

• Content-Security-Policy: require-trusted-types-for 'script'; trusted-types default;
• trusted-types default 中的 default 是必需策略名，不可省略；否则 TrustedHTML 构造失败直接抛错，不降级
• 该头只能通过 HTTP 响应头设置，meta 标签无效
• 开发阶段可用 Content-Security-Policy-Report-Only 先收集违规日志，避免上线报错中断功能

策略函数里不做 HTML 过滤

把 Trusted Types 当成“自动净化器”是典型误区。策略中写正则替换、DOMPurify.sanitize 或白名单解析，既易被绕过，又拖慢主线程。正确做法是：

• 优先改用 textContent 替代 innerHTML —— 大部分场景根本不需要渲染 HTML
• 必须插 HTML 时，用预编译模板（如 Lit 的 html tag）或服务端净化后传入
• 若需客户端动态构造，策略中只做最小转义（如 input.replace(/&/g, '&')），并明确知道它不防标签注入
• 策略返回的是字符串，Trusted Types 内部会自动包装为 TrustedHTML 对象，无需手动 new

全覆盖所有 innerHTML 类 sink

innerHTML 只是冰山一角。以下操作同样触发拦截，但常被遗漏：

• el.outerHTML = htmlString → 必须用 policy.createHTML()
• el.insertAdjacentHTML('beforeend', htmlString) → 同样拦截
• document.write(htmlString)、document.writeln()
• location.href = 'javascript:...'（属于 'script' 类别）
• 框架内部调用（如 React 的 dangerouslySetInnerHTML）是否受控，取决于框架版本是否适配 Trusted Types

防止策略被绕过的关键细节

以下写法会让整个机制完全失效：

• 用 el.setAttribute('innerHTML', ...) —— 属性名非法，不触发拦截
• 通过 shadowRoot.innerHTML（旧版浏览器可能未覆盖）
• 策略函数返回原始字符串，但未启用 CSP 或策略名未在 trusted-types 指令中声明
• 在策略中调用 eval、new Function 或拼接后 return 字符串
• 加载策略 JS 脚本前，已有代码执行了 innerHTML 赋值（策略必须早于所有 DOM 操作）

好了，本文到此结束，带大家了解了《Trusted Types 详解：彻底防御 innerHTML XSS 漏洞》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！