Content-Security-Policy 与 Subresource Integrity 实战指南:防御 XSS 与 CDN 劫持

通过 CSP 策略与 SRI 完整性校验,有效减少前端安全风险,附自动生成工具实操方法。

· 全部指南

为什么需要双重防护?

XSS 攻击通过注入恶意脚本窃取用户数据,而 CDN 资源被篡改可能导致供应链攻击。Content-Security-Policy (CSP) 通过白名单控制资源加载,Subresource Integrity (SRI) 则验证外部文件的哈希值,两者结合能有效阻断 80% 的前端攻击向量。

现代 Web 应用常依赖第三方资源,如 Google Fonts 或 Bootstrap CDN。即使你的代码安全,这些依赖仍可能成为突破口。使用 Towalles 的 csp-builder 工具时,所有策略生成均在浏览器本地完成,避免敏感配置信息外泄。

Content-Security-Policy 实战

基础 CSP 策略应包含 default-src 'self' 限制默认加载源,同时按需添加 script-src 和 style-src。使用 csp-builder 工具可交互式生成策略:添加需要的域名后,实时查看生成的 HTTP 头部,支持 nonce 和 hash 等高级模式。

部署时建议分阶段实施:先通过 report-only 模式收集违规报告,修正问题后再强制执行。Chrome 开发者工具的 Issues 面板会清晰显示 CSP 阻断的资源,帮助快速调试。

Subresource Integrity 生成技巧

为 script/link 标签添加 integrity 属性时,需计算资源的 SHA-384 哈希值。使用 sri-generator 工具只需粘贴 CDN URL,即可自动生成完整标签代码,支持 SHA-256/384/512 多种算法。

注意 SRI 需要配合 CORS 配置使用。如果资源服务器未设置 Access-Control-Allow-Origin,浏览器会拒绝加载。此时要么联系服务商调整配置,要么将资源下载到自己的可控域名下。

最佳实践与常见陷阱

避免过度宽松的策略:如 script-src * 会完全抵消 CSP 的价值。推荐使用 strict-dynamic 配合非对称加密生成的 nonce,既保证安全又便于现代框架开发。

动态内容较多的站点可采用 hash 模式。Towalles 的 sri-generator 会显示资源更新时的哈希变化提示,帮助维持长期可维护性。所有计算都在本地浏览器完成,零数据传输更安全。

上线 CSP 而不打挂生产

先用 Content-Security-Policy-Report-Only 收集一周再强制。内联脚本优先 nonce/hash,少用 unsafe-inline。脚本域名白名单保持短小;每加一个统计域名都扩大 XSS 影响面。

第三方脚本的 SRI

子资源完整性把 CDN 上的 JS/CSS 钉死在哈希。对你要发布的精确字节计算哈希;CDN 文件变更时浏览器会拦截——这正是目的。关键厂商脚本可考虑自建镜像以保证可用性。

用 Towalles 调试

CSP 导致白屏时,读控制台违规,调整策略,并用 url-parser 核对第三方 URL。在手册中记录 SRI 时,用 hash-generator 计算静态资源哈希。

把 CSP 当成反馈环

先用 Content-Security-Policy-Report-Only 收集违规,再收紧。没有白名单就上 default-src 'none' 会打断统计与编辑器。每条例外都要有负责人。

第三方脚本的 SRI

Subresource Integrity 用哈希钉住 CDN 脚本。升级库时在同一 PR 里重算哈希并更新 HTML。关键鉴权脚本在合规与运维允许时应优先自托管。

与 Towalles 配合

更新 SRI 钉扎前,用 hash-generator 核对下载的厂商文件。把 CSP 示例与发布它的应用放在同一版本库。

报告收集

把 CSP report 接到你真会看的存储。没人读的报告既浪费带宽,也掩盖部署后的真实回归。

CSP 上线纪律

动生产前先写操作程序:输入、期望输出、负责人与回滚。Towalles 上的工具便于本地检查样例,不能替代变更控制。

前置条件

  • 有代表失败案例的脱敏 fixture。
  • 清楚谁是真相来源(应用、网关、CMS 或网络设备)。
  • 能在非生产环境或用合成数据复现问题。

步骤

  1. 用 fixture 复现,记录精确命令或 UI 路径。
  2. 按需用格式化、哈希或解析工具与已知正确样例对照。
  3. 做最小修复;同一变更里避免顺手重构。
  4. 补充回归测试或清单项,避免下一任 on-call 重复踩坑。
  5. 更新 runbook:症状 → 检查 → 修复。

善后

观察 24–72 小时错误率与支持工单。若做过一次性数据修复,安排后续防止复发。工单里保留截图与哈希,不要留真实密钥。

反模式

  • 把生产密钥贴到公开页面「只是看一下」。
  • 上线却不写回滚说明。
  • 把本地绿色演示当成多区域生产的证明。

相关工具