能彻底阻断 eval 类 XSS，但必须配置 CSP 响应头 require-trusted-types-for 'script' 并声明 trusted-types default；仅 JS 创建策略无效，且需替换所有 eval、setTimeout(string)、new Function 等调用。
直接用 Trusted Types 拦住 eval 是最有效的做法——但必须配合 CSP 响应头启用强制模式，否则 JS 里写再多策略也没用。
必须先配好 CSP 响应头
浏览器只在收到 HTTP 头后才拦截 eval 调用。光在 JS 里调用 trustedTypes.createPolicy 不会产生任何防护效果。
-
生产环境必需头：
Content-Security-Policy: require-trusted-types-for 'script'; trusted-types default -
require-trusted-types-for 'script'是开关：开启后，eval("alert(1)")会立即抛TypeError -
trusted-types default中的default是强制要求的策略名；若不匹配，策略创建失败时直接报错，不会静默降级 - 不能用
设置该指令，必须走服务端响应头 - 开发阶段可用
Content-Security-Policy-Report-Only先收集违规日志，避免上线即崩
识别并替换所有 eval 使用点
eval 是明确被 Trusted Types 管控的 sink，但 legacy 项目中常以隐蔽形式存在：
- 显式调用：
eval(str)、window.eval(str) - 字符串形式的定时器：
setTimeout("doSomething()", 100)、setInterval("check()", 500) - 动态函数构造：
new Function("return " + userInput) - 第三方库内部调用（如旧版模板引擎、JSONP 回调解析器），需确认其是否兼容 Trusted Types
这些地方一旦漏掉一个，攻击者就能绕过整个防护体系。
用安全替代方案重写逻辑
Trusted Types 不提供“安全版 eval”，它的设计目标就是让这类操作无法执行——所以重构重点是移除而非封装。
- 用
JSON.parse()替代eval解析 JSON 字符串（确保输入严格为 JSON 格式） - 把动态代码逻辑提前编译为函数，例如用
Function构造器仅在可信上下文（如构建时）使用，运行时不接受用户输入 - 对配置驱动的行为，改用白名单对象查找：
const handlers = { login, logout, search }; handlers[action]?.() - 若必须执行用户定义逻辑（如低代码平台），应在沙箱环境（如 WebAssembly 或 iframe + postMessage）中运行，而非直接
eval
验证是否真正覆盖
上线前必须确认两点：所有 eval 类调用已消失，且 CSP 头已生效。
- 用浏览器 DevTools 的 Console 查看是否有
Failed to execute 'eval': This document requires 'TrustedScript' assignment报错 - 检查 Network → Response Headers，确认
Content-Security-Policy包含require-trusted-types-for 'script' - 在页面加载后运行
console.log(trustedTypes?.getPolicyNames())，应返回["default"]或对应策略名 - 对历史漏洞 URL（如含
javascript:alert(1)的 hash 或 query）做回归测试，确保不再触发脚本执行
