Trusted Types 不能彻底消除 XSS，但可阻断未封装的 innerHTML 赋值——需 CSP 头启用、策略全覆盖且无逃逸；策略非净化器，应优先用 textContent 或预编译模板。

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 或白名单解析，既易被绕过，又拖慢主线程。正确做法是：

Wechat Article Html

将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。

下载

• 优先改用 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 操作）