Angular 8项目未直接使用eval时，能否在CSP头禁用eval？有部署副作用吗？

核心判定逻辑 #

哪怕业务代码中没有直接手写调用eval，也无法直接判定可以在CSP头中安全禁用eval类执行权限。CSP对eval类执行的拦截范围，远大于开发者直接编写的eval语句，所有具备动态代码解析执行语义的逻辑，都会被纳入拦截规则。

CSP拦截eval的覆盖范围 #

通过移除script-src指令下的'unsafe-eval'参数实现禁用效果时，以下场景都会被直接拦截：

• 代码中直接调用的eval()函数
• 通过new Function()构造函数生成可执行代码
• 给setTimeout()、setInterval()传递字符串格式的代码参数（而非函数引用）
• 第三方库、框架内部封装的动态代码执行逻辑（这类逻辑不会出现在业务源码中，但运行时会触发拦截）

上线后可能出现的运行错误触发点 #

未充分排查就直接配置禁用'unsafe-eval'时，Angular 8项目常见的运行时异常包括：

• 构建未开启AOT编译：Angular 8默认生产构建开启AOT编译，但如果人为关闭AOT配置、或在运行时动态加载未做预编译的组件/模块，Angular自带的JIT编译器会内部调用new Function生成组件渲染逻辑，直接触发CSP拦截，导致组件白屏、模块加载失败。
• 第三方依赖的隐性触发：很多老旧版本的UI组件库、工具类库、jQuery生态插件，内部会用new Function实现模板渲染、参数解析逻辑，这类代码无业务层感知，是上线后最容易漏查的异常来源。
• 构建参数环境不一致：本地开发使用带JIT的开发构建测试通过，但上线前未对齐生产构建参数（比如误关闭aot、optimization选项），导致线上产物携带了运行时编译逻辑，和本地测试环境的行为不匹配。

安全落地的操作步骤 #

• 全局扫描业务代码、依赖包中的所有eval、new Function调用，评估对应逻辑是否可替换为无动态执行的实现。
• 构建和线上配置完全一致的生产包，先配置Content-Security-Policy-Report-Only头开启CSP仅报告模式（不做实际拦截），完整走通所有业务流程，收集所有触发eval类拦截的上报，确认无违规后再切换为实际拦截的CSP配置。
• 若排查后发现必须保留某一处触发eval的逻辑，可单独为对应路径的脚本配置豁免，无需全局放开'unsafe-eval'权限。

内容的提问来源于stack exchange，提问作者myName_Question