Content Security Policy 实战指南与常见误区解析
一一然我为什么又在搞 CSP 这玩意？
上个月项目上线前安全扫描，扫出一堆 CSP 风险，甲方爸爸直接甩了一页报告过来，说不加 Content Security Policy 就不算交付。没办法，前端背锅侠的命，谁叫我们管 DOM 呢。
其实我一直觉得 CSP 是那种“知道它好但总懒得配”的东西，直到这次被逼到墙角，才真正把几个主流方案从头到尾撸了一遍。今天就聊聊我的实战体验：三种最常见的 CSP 实现方式——内联 meta 标签、HTTP 头设置、以及通过构建工具动态注入策略。谁省事？谁灵活？谁坑最多？我都踩过了，你别再重蹈覆辙。
先说结论：我选 HTTP 头 + 动态生成
如果你现在就想抄作业，直接记这个：用 Nginx 或后端服务加 Content-Security-Policy 响应头，配合一个可配置的策略生成器（比如 Node.js 写个小中间件），比啥都强。
meta 标签虽然简单，但功能残废；构建工具注入看着酷，改一次部署得重新打包，烦死了。只有 HTTP 头，热更新、支持 nonce、可以按环境切换策略，真·生产级玩法。
方案一：meta 标签，新手村专属
最简单的写法，直接在 HTML 里塞个 meta：
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://jztheme.com; img-src *; object-src 'none'">这招适合静态页面、小 demo 或者测试环境快速验证。优点是改完刷新就行，不用动服务器配置。但问题也一大堆：
- 不支持某些高级指令，比如 report-to、worker-src 在部分浏览器下无效
- 没法做动态 nonce，想防内联脚本攻击？基本没戏
- 一旦项目大了，策略分散在多个 HTML 文件里，维护起来像考古
我之前在一个多页应用里试过这套，结果 QA 发现某个子页面漏加了策略，XSS 直接打穿。后来统一收口，全砍掉换成服务端下发。
方案二：构建时注入，看似聪明实则自找麻烦
有些团队喜欢在 webpack 打包时，把 CSP 策略写进 index.html。比如用 HtmlWebpackPlugin 插件动态插入：
new HtmlWebpackPlugin({
template: 'src/index.html',
cspMeta: <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' 'unsafe-inline'">
})模板里用占位符接收：
<head>
<!-- other head content -->
<%= htmlWebpackPlugin.options.cspMeta %>
</head>初看挺优雅，策略集中管理，还能根据不同 mode 切换。但实际用下来，坑不少：
- 开发环境和生产环境策略不同，但每次改都要重新 build，本地调试特别慢
- 如果用了 CDN 缓存 HTML，更新策略后缓存失效难控制
- 遇到需要动态 nonce 的场景，build 时根本拿不到运行时值，只能退化成
'unsafe-inline'，等于白配
折腾了半天发现，这方案更适合纯静态站点，且对安全性要求不高的场景。我们项目后来直接弃用了。
谁更灵活？谁更省事？
灵活性方面，HTTP 头完胜。你可以根据请求路径、用户身份、甚至 AB 测试组返回不同的策略。比如后台管理系统给管理员放宽一点 script-src，普通用户收紧，都可以做到。
省事程度的话……meta 标签一开始最省事，但越往后越费劲；HTTP 头前期要搭点基础设施，比如写个策略中间件，但后面一劳永逸。
举个例子，我们要加 analytics 脚本，来源是 https://jztheme.com/analytics.js。如果是 meta 方案，得改所有页面模板；构建注入得重新打包发布；而 HTTP 头只需要改一行配置，reload 一下 Nginx 就生效了。
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://jztheme.com; style-src 'self' 'unsafe-inline'; img-src *; object-src 'none';";核心代码就这几行
我现在用的是 Express + 中间件的方式生成 CSP header，方便调试也容易扩展：
function cspMiddleware(req, res, next) {
const isDev = process.env.NODE_ENV === 'development';
const nonce = Buffer.from(crypto.randomUUID()).toString('base64');
let policy =
default-src 'self';
script-src 'self' ${isDev ? "'unsafe-eval'" : ''} 'nonce-${nonce}';
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
font-src 'self';
connect-src 'self' https://jztheme.com;
object-src 'none';
base-uri 'self';
form-action 'self';
.replace(/s{2,}/g, ' ').trim();
res.setHeader('Content-Security-Policy', policy);
res.locals.nonce = nonce; // 传给模板引擎用
next();
}然后在返回的 HTML 里使用 nonce：
<script nonce="<%= nonce %>">
console.log('This is allowed');
</script>这样既防止了未知来源的脚本执行，又能跑 inline 脚本，完美解决历史项目中大量内联 JS 的问题。
踩坑提醒：这三点一定注意
1. report-uri 已废弃，别再用了。现在要用 Content-Security-Policy-Report-Only 和 report-to 指令配合上报端点。但注意，很多老浏览器不支持，上报失败也没提示，得自己埋监控。
2. Chrome 开发者工具里的警告要看清，有时候只是 eval 被拦了，不影响功能，但日志刷屏吓死人。学会区分哪些是真实风险，哪些是噪音。
3. 第三方库可能偷偷插脚本，比如某个 UI 库用了 innerHTML 渲染 icon，就会触发 unsafe-inline 限制。建议先用 Report-Only 模式跑几天，收集 violations 再正式拦截。
我的选型逻辑
我的标准很简单：能不能快速迭代？能不能按需调整？会不会拖慢发布流程？
meta 标签和构建注入都违反了“快速迭代”原则——改个策略要走 CI/CD，等部署，太重了。而 HTTP 头只要改配置，重启或 reload 即可生效，配合灰度发布还能逐步放量，安全感拉满。
再说扩展性。未来要做微前端？子应用独立域名加载 JS？HTTP 头策略可以直接加 domain 白名单，其他方案就得改源码或者重建资源，根本不现实。
以上是我的对比总结，有不同看法欢迎评论区交流
我知道有人坚持用 meta 标签，尤其是一些静态博客平台确实只能这么干。也有团队用 Terraform 把 CSP 当基础设施管理，也算合理。但我个人经验来看，只要有一点复杂度的项目，最终都会走向服务端动态控制 CSP。
这东西不是配完就完事的，是个持续优化的过程。初期宽松点没关系，关键是建立可观测性——能看到谁违规、为什么违规，才能一步步收紧策略。
别像我一样，第一次上线直接上 strict policy，结果整个页面白屏，排查两小时才发现忘了加 connect-src……
暂无评论