CHROME扩展开发实战：绕过unsafe-eval限制的CSP策略调整-CSDN博客

1. 从“拒绝求值”到“策略调整”：一个真实开发场景的引入

最近在折腾一个Chrome扩展，想给它的选项页（Options Page）做个漂亮点的界面，就顺手用上了Vue 3。本地开发一切顺利，组件写得飞起，数据响应式绑定也丝滑无比。结果，当我兴冲冲地把扩展打包，加载到Chrome里准备测试时，浏览器控制台直接给我泼了一盆冷水，一个鲜红的错误蹦了出来：

Uncaught EvalError: Refused to evaluate a string as JavaScript because ‘unsafe-eval’ is not an allowed source of script...

相信很多刚开始接触Chrome扩展开发，尤其是用了现代前端框架（Vue、React等）的朋友，都踩过这个坑。那一刻的心情，就像你组装好一台新电脑，按下开机键却只听到“嘀”的一声报警，屏幕一片黑。这个错误的核心，指向了浏览器里一个非常重要的安全机制——内容安全策略，也就是我们常说的 Content Security Policy，简称 CSP。

简单来说，CSP就像是给你扩展的页面请了一位严格的保安。这位保安有一份白名单，名单上写着哪些来源的脚本、样式、图片等资源是可信的，可以放行执行。而eval()这个函数，以及类似的Function()构造函数、setTimeout/setInterval传入字符串等动态代码执行方式，在保安眼里属于“高危操作”，因为它们允许将字符串当作代码来执行。如果恶意脚本被注入，通过eval执行，后果不堪设想。因此，为了安全起见，Chrome扩展默认的CSP策略是完全禁止unsafe-eval（不安全求值）的。

那么问题来了，为什么我用Vue开发就触发了这个限制呢？这是因为Vue的模板编译器，在开发模式下，有时会依赖new Function()来动态生成渲染函数，以提高开发体验。这就触碰了CSP的禁区。所以，错误不是Vue的“锅”，而是我们扩展的默认安全策略与框架的某些工作模式产生了冲突。要解决它，我们不能去削弱安全，而是需要学会如何正确地与这位“保安”沟通，调整它的白名单规则。这就是我们接下来要深入探讨的：如何在manifest.json中调整CSP策略，在必要的时候启用unsafe-eval，并理解不同扩展版本（Manifest V2 和 V3）在这件事上的根本区别。

2. 理解CSP：你的扩展安全守门员

在动手修改配置之前，我们得先搞清楚这位“保安”到底是谁，它的规则是什么。Content Security Policy 绝非Chrome扩展独有的概念，它是现代Web应用一道至关重要的安全防线，主要用于防御跨站脚本攻击等数据注入攻击。对于Chrome扩展而言，CSP的作用更为关键，因为扩展拥有比普通网页更高的权限（比如访问浏览器API、跨域请求等），一旦被恶意代码攻破，危害也更大。

Chrome为每个扩展的页面（包括后台页面、选项页、弹出页以及注入的内容脚本所控制的页面）都施加了一个默认的CSP。这个默认策略非常严格。我们可以通过一个简单的实验来感受一下：创建一个最基本的扩展，它的manifest.json里只定义了一个后台页面，然后在这个后台页面的HTML里，尝试插入一段内联的<script>标签，或者用eval执行一段字符串。

// manifest.json (Manifest V3)
{
  "manifest_version": 3,
  "name": "CSP Test",
  "version": "1.0",
  "background": {
    "service_worker": "background.js"
  }
}

<!-- 假设这是我们的后台页面，通过chrome-extension://xxx/background.html访问 -->