Trusted Types 不能消除 eval 风险，它仅约束 innerHTML、document.write、setTimeout(string) 等特定 DOM sink，对 eval、new Function 等纯 JS 执行入口完全不拦截。
Trusted Types 不能消除 eval 风险，它压根不作用于 eval。
Trusted Types 是浏览器原生机制，只约束特定的「危险 DOM sink」——比如 innerHTML、document.write、setTimeout（字符串形式）、setInterval（字符串形式）等。它对 eval、Function 构造函数、JSON.parse、atob 后再 eval 等纯 JavaScript 执行入口完全无感。
你写 eval('alert(1)')，Trusted Types 不会拦截、不报错、不警告，浏览器照常执行。
Trusted Types 能管住哪些地方
- 它只在启用后对指定 sink 强制要求传入
TrustedHTML/TrustedScript/TrustedScriptURL类型值 - 常见受控点：
element.innerHTML = ...document.write(...)-
location.href = ...（当配置了TrustedScriptURL策略时） -
setTimeout('...', 100)和setInterval('...', 100)
- 它不拦截：
eval、new Function、postMessage、fetch返回后拼接再eval、WebAssembly.instantiate等
为什么有人误以为它能防 eval
常见混淆场景：
- 把
setTimeout('alert(1)')当成eval—— 实际上它是独立 sink，Trusted Types可拦截它，但和eval无关 - 在 CSP 中同时启用了
require-trusted-types-for 'script'和unsafe-eval禁用，误把后者功劳归给前者 - 混淆了「防止 DOM-based XSS」和「防止代码注入执行」两个不同攻击面
真正压制 eval 的手段只有这些
-
CSP 的
unsafe-eval禁用：最直接有效Content-Security-Policy: script-src 'self' 'unsafe-inline';→ 移除'unsafe-eval'后，所有eval、new Function、setTimeout(string)全部抛EvalError -
静态检测工具强制拦截：
eslint-plugin-security的detect-eval-with-expression规则 + CI 卡点sonarqube或semgrep自定义规则扫描eval(、new\s+Function( -
运行时沙箱隔离（极少数必要场景）：
使用vm2（Node.js）或SecureContext+iframe sandbox（前端）限制全局访问，但无法覆盖所有 JS 引擎行为，且性能开销大
真正要“彻底消除 eval 风险”，靠的不是某一个 API，而是三层卡控：CSP 拦第一道（运行时）、ESLint 拦第二道（开发时）、Code Review 拦第三道（人工确认）。任何单点方案都存在绕过路径。
