如何通过Trusted Types与CSP协同构建高效的企业级前端安全白名单？

本文共计1132个文字，预计阅读时间需要5分钟。

Trusted Types 不是独立的补丁，而是与 CSP 协同工作的强制校验机制。它真正起效的前提是 CSP 中启用了 require-trusted-types-for 'script'，否则所有 DOM 注入 API（如 innerHTML、eval、script.src 等）都将直接接收字符串——这等同于将内核响应堆栈的物理密钥转换成一张便利签条。

一、CSP 必须配置两个核心指令

仅声明 trusted-types 策略名，却不启用强制校验，策略形同虚设。生产环境必须同时设置：

• trusted-types：定义允许创建的策略名称白名单，例如 securePolicy default es-module-shims。不建议用 *，应明确列出每个业务模块或第三方库所需的策略名（如 react-html、vue-template）；
• require-trusted-types-for 'script'：强制所有高危 DOM 操作只接受 TrustedHTML、TrustedScriptURL 等类型对象。该指令目前仅支持 'script' 和 'all'，'style' 尚未被主流浏览器广泛支持，暂不启用。

典型生产头示例：

Content-Security-Policy: trusted-types securePolicy default es-module-shims; require-trusted-types-for 'script'; default-src 'self'; script-src 'self' 'nonce-abc123';

二、策略命名需按职责隔离，拒绝“一策通吃”

一个全局 default 策略看似省事，实则破坏最小权限原则。不同模块的数据来源、信任边界和净化逻辑完全不同：

立即学习“前端免费学习笔记（深入）”；

• 富文本渲染模块应使用 rich-text-sanitizer 策略，内部调用 DOMPurify.sanitize() 并返回 TrustedHTML；
• 动态脚本加载器（如微前端子应用注入）应使用 dynamic-script-loader，仅允许来自预设 CDN 域名的 https://cdn.example.com/*.js 脚本 URL；
• 框架适配层（如 React 的 dangerouslySetInnerHTML 替代方案）应绑定专属策略，禁止传入任意 HTML 字符串，只接受经框架自身 sanitizer 处理后的可信对象。

策略创建必须在页面初始化早期完成，且不可重复注册同名策略（除非显式加 allow-duplicates，仅用于灰度兼容）。

三、与现代前端框架和工具链深度对齐

Trusted Types 不是“写个策略就完事”，它必须嵌入开发流程中才能持续生效：

• ES Module Shims：自动注册 es-module-shims 策略，但前提是 CSP 已声明该名称，并启用 require-trusted-types-for。若使用 Wasm 版本，还需在 script-src 中加入 'unsafe-wasm-eval'；
• React/Vue/Angular：框架本身不自动创建 Trusted Types 策略。需手动封装 createPolicy，并在 dangerouslySetInnerHTML 或 v-html 使用前做转换。Angular 的 DomSanitizer.bypassSecurityTrustHtml() 返回值已是 TrustedHTML，可直接接入；
• 构建时检查：在 CI 流程中加入 trusted-types-checker 类工具，扫描源码中所有 innerHTML=、eval(、setInterval( 等调用点，确保其输入必经策略处理，否则阻断发布。

四、渐进落地：从上报模式过渡到强制拦截

上线初期不建议直接开启强制拦截，避免误伤正常逻辑。推荐分三步走：

• 第一阶段：使用 Content-Security-Policy-Report-Only + report-to，收集所有违反 Trusted Types 的调用栈，定位存量风险点；
• 第二阶段：对高频违规模块（如评论区、搜索结果高亮）优先接入策略，其余模块保留 default 策略并记录日志；
• 第三阶段：全量启用 Content-Security-Policy 强制模式，并将策略名白名单收紧为仅包含已验证的模块名，移除 * 和 allow-duplicates。

整个过程需配合监控看板，实时统计策略命中率、拒绝次数和 top 违规源，形成闭环反馈。