开发中遇到的内容安全策略错误如何快速定位与解决

内容安全策略错误的常见表现

在本地调试页面时一切正常，但一部署到线上就发现某些资源加载失败，比如图片出不来、脚本不执行，或者控制台突然冒出一串红色错误："Refused to load the script" 或 "Content Security Policy" 相关提示。这类问题八成是内容安全策略（CSP）在起作用。

比如你在页面里引入了 CDN 上的 jQuery，本地没问题，上线后却报错无法加载。这时候别急着怀疑网络，先看浏览器开发者工具的 Console 和 Network 标签页，通常会明确告诉你哪个资源被 CSP 拦截了。

CSP 是怎么拦住资源的

内容安全策略本质上是一套由 HTTP 响应头 Content-Security-Policy 定义的规则，用来限制页面可以加载哪些外部资源，比如脚本、样式、图片、字体等。它的初衷是防止 XSS 攻击，比如黑客注入恶意脚本时，因不符合 CSP 规则而无法执行。

但对开发者来说，它也可能误伤“自己人”。例如你从 unpkg 引入一个工具库：

<script src="https://unpkg.com/lodash"></script>

如果服务器的 CSP 没有允许 https://unpkg.com，这个请求就会被浏览器直接拦截。

如何查看当前的 CSP 规则

打开浏览器开发者工具，切换到 Network 选项卡，刷新页面，点击文档请求（通常是 HTML 文件），在 Response Headers 里找 Content-Security-Policy 字段。你会看到类似这样的内容：

default-src 'self'; script-src 'self' https://cdn.jsdelivr.net; style-src 'self' 'unsafe-inline'

这表示：默认只允许加载同源资源，脚本可以来自自身和 jsdelivr 的 CDN，样式允许内联。

常见的 CSP 错误场景与修复方式

场景一：使用了内联脚本或内联样式。很多前端框架为了性能会在构建时生成一些内联代码，但 CSP 默认禁止这种做法。如果你看到错误提示 “Refused to execute inline script”，说明需要在策略中加入 'unsafe-inline'，但这不推荐，因为会降低安全性。更优方案是使用 nonce 或 hash 机制。

例如给脚本添加唯一标识：

<script nonce="2726c7f26c">console.log('Hello')</script>

然后在 CSP 中声明：

script-src 'nonce-2726c7f26c'

场景二：加载第三方 API 或资源。比如项目用了百度地图，需要加载外部 JS，但没在 script-src 中列出对应域名。解决方法是在策略中添加信任的源：

script-src 'self' https://api.map.baidu.com

场景三：动态创建 script 标签。有些轮播图插件或埋点脚本会通过 document.createElement('script') 动态插入，这类行为可能被 CSP 阻止。如果确定来源可信，需确保其目标域名已在 script-src 白名单中。

开发环境如何模拟 CSP 限制

别等到上线才发现问题。可以在本地开发服务器上手动设置 CSP 头。比如用 Node.js + Express：

app.use((req, res, next) => {
  res.setHeader('Content-Security-Policy', "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'");
  next();
});

这样就能提前暴露潜在的加载问题。

过度宽松的 CSP 同样危险

有人图省事直接写 script-src *，以为万事大吉。实际上这等于关闭了防护，任何第三方脚本都能运行，XSS 风险大增。正确的做法是精确控制每个资源类型允许的来源，宁可多试几次报错，也不要牺牲安全。

还可以利用 report-uri 或 report-to 字段，让浏览器在发生 CSP 冲突时发送报告，帮助你在不影响用户体验的前提下收集违规行为，逐步优化策略。