trusted types 不能彻底杜绝 xss，但能大幅收窄 dom 型 xss 利用路径；需配对 csp 指令、避免策略内 html 过滤、全覆盖高危 sink、防止策略外挂与间接调用。

Trusted Types 不能“彻底杜绝” XSS 风险，但它能从执行源头大幅收窄 DOM 型 XSS 的利用路径——前提是策略不被绕过、sink 全覆盖、且不依赖字符串拼接做净化。 下面从落地关键点出发，讲清楚怎么用它真正提升防护水位：

必须配对 CSP 指令才能生效

Trusted Types 是浏览器运行时机制，不是代码检查工具。它只在 CSP 头启用后才拦截非法调用：

• trusted-types：声明允许创建的策略名，例如 trusted-types default securePolicy;；设为 'none' 则禁止任何策略
• require-trusted-types-for 'script'：强制所有高危 DOM 操作（innerHTML、insertAdjacentHTML、eval、setTimeout(string) 等）只接受 Trusted Type 对象
• 漏掉任一指令，整个机制形同虚设；仅加策略 JS 而不配 CSP，完全不拦截

策略里别写 HTML 过滤逻辑

常见误区是把 Trusted Types 当成“自动转义器”，在策略函数里手动解析、正则替换或白名单过滤 HTML 字符串。这既危险又低效：

• 正则难覆盖所有绕过变体（如 innerHTML），易被绕过
• 性能开销大，尤其在高频渲染场景下
• 正确做法是：优先用 textContent 替代 innerHTML；必须插 HTML 时，用预编译模板或 DOMPurify 在策略外净化，再包装成 TrustedHTML

覆盖全部 sink，不只是 innerHTML

攻击者会主动寻找未受控的入口。以下 API 同样属于高危 sink，必须纳入策略管控：

• el.insertAdjacentHTML(position, html)
• document.write() / document.writeln()
• location.href（当赋值含 javascript: 时）
• eval()、setTimeout(string)、setInterval(string)
• Element.setAttribute('onxxx', ...)（部分浏览器已支持拦截）

框架如 React/Vue 内部调用这些 API 时，需确认其版本是否兼容 Trusted Types；否则可能逃逸防护。

避免策略外挂和间接调用漏洞

以下写法会让 Trusted Types 完全失效：

• 用非标准方式触发 sink，例如 el.setAttribute('innerHTML', html)（属性名无效，不触发拦截）
• 通过 Web Components 的 shadowRoot.innerHTML（部分旧版浏览器未拦截）
• 策略函数返回原始字符串而非 TrustedHTML 对象（浏览器拒绝接收，但若策略未启用或被跳过，则直接执行）
• 使用 trustedTypes.createPolicy('default', {...}) 但未在 CSP 中显式列出 default 名称，导致浏览器回退到宽松默认策略

不复杂但容易忽略。