script-src详解与实战踩坑经验分享

我的写法，亲测靠谱

在前端安全这块儿，script-src 是一个非常重要的配置项。它能帮助我们防止一些常见的 XSS 攻击。我一般这样处理：

Content-Security-Policy: script-src 'self' https://jztheme.com/api;

这里 script-src 的值是 'self' 和 https://jztheme.com/api。'self' 表示只允许加载当前域名下的脚本，而 https://jztheme.com/api 则是允许从这个特定的 API 地址加载脚本。

这种写法更靠谱，因为：

• 限制了脚本的来源，减少被恶意脚本攻击的风险。
• 明确指定哪些外部资源可以加载，增强了安全性。

当然，如果你有其他需要信任的第三方脚本，也可以添加到这个列表中。比如：

Content-Security-Policy: script-src 'self' https://jztheme.com/api https://cdn.example.com;

这样就更灵活了，但也增加了管理的复杂度，所以要权衡利弊。

这几种错误写法，别再踩坑了

在实际项目中，我见过不少开发者犯了一些低级错误，导致脚本加载出现问题或者安全漏洞。以下是一些常见的错误写法：

• 不限制任何来源：

Content-Security-Policy: script-src *;

这种写法太宽松了，相当于没有任何限制。虽然脚本可以正常加载，但安全性大打折扣，很容易被恶意脚本利用。

• 忽略 'self'：

Content-Security-Policy: script-src https://jztheme.com/api;

这种写法忽略了 'self'，会导致当前域名下的脚本无法加载。我在一个项目里就踩过这个坑，折腾了半天才发现问题出在这儿。

• 使用 unsafe-inline：

Content-Security-Policy: script-src 'self' 'unsafe-inline';

虽然 unsafe-inline 可以让你直接在 HTML 中嵌入脚本，但这会带来极大的安全风险。除非你非常清楚自己在做什么，否则建议避开这种方式。

• 混淆 script-src 和 style-src：

Content-Security-Policy: style-src 'self' https://jztheme.com/api;

这种写法把样式和脚本搞混了。虽然不影响脚本加载，但会导致样式加载出现问题。一定要区分清楚这两个配置项。

实际项目中的坑

在实际项目中，配置 script-src 时还有一些需要注意的地方：

• 不要忘记测试： 配置完 script-src 后，务必进行充分的测试，确保所有必要的脚本都能正常加载。有时候一个小疏忽就可能导致整个页面挂掉。
• 动态更新 CSP 头： 如果你的项目有多个环境（如开发、测试、生产），可能需要动态更新 CSP 头。可以通过服务器端配置来实现这一点。例如，在 Node.js 中可以用 helmet 库来管理 CSP 头：

const helmet = require('helmet');
app.use(helmet.contentSecurityPolicy({
  directives: {
    defaultSrc: ["'self'"],
    scriptSrc: ["'self'", "https://jztheme.com/api"]
  }
}));

这样可以更灵活地控制不同环境下的 CSP 策略。

以上是我总结的最佳实践，希望对你有帮助。如果有更好的方案或遇到什么问题，欢迎评论区交流。