安全头配置实战：提升Web应用防护能力的关键策略

我的写法，亲测靠谱

安全头（Security Headers）这东西，说白了就是给 HTTP 响应加几行 header，防 XSS、防点击劫持、防内容嗅探……听起来挺简单，但真在项目里用起来，坑不少。我一开始也以为配几个 CSP 就完事了，结果上线后各种报错、白屏、资源加载失败，折腾了好几天。

现在我一般这样处理：先在开发环境用 Content-Security-Policy-Report-Only 模式跑一周，收集所有违规上报，再根据日志调整策略，最后才切到正式的 Content-Security-Policy。这个流程虽然啰嗦，但能避免线上事故。下面是我目前在用的一套配置，基于 Express + Nginx 的组合：

// Express 中间件（开发阶段）
app.use((req, res, next) => {
  res.setHeader('Content-Security-Policy-Report-Only', 
    "default-src 'self'; " +
    "script-src 'self' 'unsafe-inline' https://cdn.jsdelivr.net; " +
    "style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; " +
    "img-src 'self' data: https://*.jztheme.com; " +
    "font-src 'self' https://fonts.gstatic.com; " +
    "connect-src 'self' https://jztheme.com/api; " +
    "frame-ancestors 'none'; " +
    "report-uri /csp-report"
  );
  next();
});

注意这里用了 'unsafe-inline'，别急着骂——很多老项目里内联脚本和样式根本没法立刻移除，硬砍会导致功能崩掉。我的策略是：先允许，但记录所有违规，等前端团队逐步重构后再干掉它。另外，frame-ancestors 'none' 是防点击劫持的核心，比 X-Frame-Options 更灵活，而且兼容性现在也够了。

上线前，我会把 -Report-Only 去掉，换成正式策略。同时，Nginx 层也会加一层兜底：

add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options DENY;
add_header Referrer-Policy strict-origin-when-cross-origin;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=()";

为什么还要在 Nginx 加？因为万一 Node 服务挂了，静态资源（比如错误页）还能靠 Nginx 返回基础安全头。别小看这个，我们有一次 API 网关故障，用户看到的是 Nginx 的 502 页面，就因为有 X-Frame-Options，才没被嵌到钓鱼网站里。

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

我见过太多人把安全头配成“自我安慰”模式。最典型的错误是：CSP 里直接写 script-src *。这等于没设！攻击者随便注入个远程脚本就能搞你。还有人为了省事，把 'unsafe-eval' 和 'unsafe-inline' 全开，那 CSP 还有什么意义？

另一个大坑是 report-uri 没做验证。我曾经收到过几千条假上报，全是攻击者伪造的 CSP 报告，塞满数据库。后来改成只接受 JSON 格式，并且校验来源域名，才稳住。建议你的 /csp-report 接口至少加个简单的过滤：

app.post('/csp-report', (req, res) => {
  if (!req.is('application/csp-report')) {
    return res.status(400).end();
  }
  const report = req.body['csp-report'];
  // 可选：只记录来自自己域名的报告
  if (report && report['document-uri']?.includes('yourdomain.com')) {
    logToDB(report);
  }
  res.status(204).end();
});

还有人把 Content-Security-Policy 和 Content-Security-Policy-Report-Only 同时发出去。浏览器会优先用前者，后者被忽略，但有些老客户端会混乱。千万别这么干。

最离谱的一次，同事在测试环境配了 CSP，但忘了关 report-only，上线后以为生效了，结果三个月后才发现所有策略都是“只读模式”——等于裸奔。这种低级错误，靠自动化测试能避免，但很多人懒得写。

实际项目中的坑

真实项目里，CSP 最头疼的不是技术，而是协作。比如产品突然说“要加个第三方统计脚本”，运营要嵌个 YouTube 视频，市场部要放个 Hotjar 录屏工具……每个都得往 CSP 里加白名单。我现在的做法是：建立一个“安全头变更清单”，任何新增外部资源必须走 PR，附带安全评估。

动态加载的场景也麻烦。比如用 import() 动态加载模块，如果模块 URL 是运行时生成的，CSP 里的 script-src 很难覆盖。这时候要么用 nonce，要么用 hash。我试过 nonce，但 SSR 渲染时每个请求都要生成唯一值，性能开销不小。后来改用 hash，配合构建工具自动提取脚本内容生成 hash 值：

// webpack 插件示例（简化版）
compilation.hooks.processAssets.tap('CSPHashPlugin', () => {
  const script = compilation.assets['main.js'].source();
  const hash = crypto.createHash('sha256').update(script).digest('base64');
  // 注入到 HTML meta 或 header
});

不过 hash 方案对动态内容不友好，比如带时间戳的脚本（app.js?v=123），hash 会变。所以现在我更倾向用 nonce + 严格限制 strict-dynamic，但得确保所有脚本都通过可信入口加载。

另外，别忘了 Safari 对 CSP 的支持有点怪。比如 frame-ancestors 在旧版 Safari 里不认，还得保留 X-Frame-Options 作为 fallback。测试时一定要覆盖 Safari，别只看 Chrome DevTools 的绿勾。

最后提一句：安全头不是一劳永逸的。我每个月会跑一次 securityheaders.com 扫描，看看有没有新漏洞。上次发现漏了 Permissions-Policy，赶紧补上，防止摄像头被偷偷调用。

结尾碎碎念

以上是我这几年踩坑后总结的实战经验。说实话，没有完美的方案——开太严影响业务，开太松等于没设。我的原则是：核心页面（登录、支付）必须严格，营销页可以适当宽松，但要有监控和快速回滚机制。

这套配置在几个中大型项目里跑了几个月，没出过安全事件，偶发的 CSP 报警也能快速定位。如果你有更好的方案，比如怎么优雅处理第三方 widget 的 CSP 冲突，或者如何自动化管理 nonce，欢迎评论区交流。毕竟安全这东西，一个人想不周全，多个人一起踩坑才能少掉坑。