如何利用 Trusted Types 彻底消除旧项目中遗留的 eval 并实现安全审计-js教程-PHP中文网

trusted types 本身不处理 eval，仅管控 dom 层高危注入（如 innerhtml、script.src）；eval 属 javascript 引擎层动态执行，需通过静态分析、运行时拦截与重构专项治理，trusted types 仅作辅助验证。

如何利用 trusted types 彻底消除旧项目中遗留的 eval 并实现安全审计

Trusted Types 本身不处理 eval，它只管控 DOM 层的高危注入（如 innerHTML、script.src 等）。而 eval 是 JavaScript 引擎层的动态执行机制，属于完全不同的安全域。要彻底消除旧项目中遗留的 eval，必须结合静态分析、运行时拦截与重构策略，Trusted Types 只能作为辅助验证环节，不能替代对 eval 的专项治理。

识别所有 eval 及等效危险调用

先明确哪些代码模式等同于 eval 的风险等级：

eval()、Function() 构造函数（传入字符串参数）
setTimeout(string, ...)、setInterval(string, ...)
new Function(...)（尤其带动态拼接参数的）
第三方库中隐式使用 eval 的模块（如某些老版本模板引擎、JSONP 工具）

建议用 ESLint 插件 @typescript-eslint/no-implied-eval 或自定义规则扫描全量 JS/TS 代码；也可借助 untrusted-types Chrome 扩展在运行时捕获实际触发点，定位真实调用上下文。

分阶段替换：从阻断到重构

直接删除 eval 往往导致功能断裂，需按风险和可控性分级处理：

高危且可替代：如 JSON 解析改用 JSON.parse()；模板渲染迁移到安全的编译型方案（如 Handlebars 预编译、Lit 模板）
中危且需封装：将 Function 构造逻辑收口到统一工厂函数，并加入白名单校验（例如只允许预设函数名 + 固定参数结构）
低频但难删：对历史插件系统或配置驱动逻辑，引入沙箱环境（如 vm2 在服务端，或 iframe + postMessage 在前端隔离执行）

禁止“用 eval 拼 HTML 再塞进 innerHTML”这类双重危险组合——Trusted Types 会拦住后半步，但前半步已造成代码执行风险。

用 CSP + Trusted Types 做兜底防护

即使完成 eval 清理，也需防止未来误引入。通过 CSP 强制约束：

添加 Content-Security-Policy: script-src 'self'; unsafe-eval → 改为 script-src 'self'（移除 unsafe-eval）
配合 require-trusted-types-for 'script'，使任何未走可信策略的 DOM 注入立即报错
开发期启用 Content-Security-Policy-Report-Only 收集违规日志，确认无残留 eval 或绕过行为

注意：eval 被禁用后，浏览器控制台调试仍可用，但生产环境脚本将无法执行。