上线前该检查的 HTTP 安全响应头

六个该配的响应头

CSP 别一次写死

先用 Content-Security-Policy-Report-Only 观察误报，再切到真正拦截。尽量用 nonce 或哈希 代替 unsafe-inline；外链脚本要显式列出域名。

两个容易踩的坑

• HSTS 难回退：一旦开启 includeSubDomains + preload，子域名将长期无法走 HTTP，确认所有子域都支持 HTTPS 再开；
• 只在边缘节点加：CDN 加了源站没加，攻击者打到源站就绕过了。建议源站与应用层都设置。

怎么验证

用 curl -I https://你的域名 看响应头，或用在线安全头扫描复核。先确保核心业务不受影响，再逐步收紧策略。

实战案例：三个被安全头拦住的集成

1. iframe 嵌入变成空白：站点默认 X-Frame-Options: DENY，合作方嵌入后整块空白。若确实需要被嵌入，应改用 CSP 的 frame-ancestors 精确列出允许来源。
2. CDN 脚本被 CSP 拦下：加了 Content-Security-Policy 却在 script-src 漏掉 CDN 域名，页面功能整体失效。上线 CSP 先用 Content-Security-Policy-Report-Only 观察，再切强制模式。
3. HSTS 把测试域锁死：对通配域下发 Strict-Transport-Security 且带 includeSubDomains，而测试子域尚未配 HTTPS，浏览器将长期拒绝降级访问。上线前先确认所有子域支持 HTTPS。

常见问题（FAQ）

安全头在哪一层设置？建议在边缘（CDN / 网关）统一设置避免各服务遗漏，但 CSP 常需按应用微调。X-Content-Type-Options 有什么用？阻止浏览器“猜”内容类型，避免把上传的文本当脚本执行。CSP 能防 XSS 吗？能显著降低风险，但不能替代输出转义与输入校验。Referrer-Policy 怎么选？推荐 strict-origin-when-cross-origin：同源保留完整来源，跨源只给源站域名。

CSP 的渐进式落地

CSP 一旦配错会直接打断页面功能，因此必须分阶段推进：

1. 先上 Report-Only：用 Content-Security-Policy-Report-Only 只上报不拦截，观察一到两周的真实违规；
2. 收集上报端点：配置 report-to / report-uri 并集中分析，区分“必须修”的内联脚本与第三方资源；
3. 消灭内联脚本：把内联脚本改为外链或用 nonce，unsafe-inline 一旦保留，CSP 的防 XSS 价值会大打折扣；
4. 逐步收紧指令：先固定 default-src 与 script-src，再补 img-src、connect-src、frame-ancestors；
5. 最后切强制模式：确认违规日志已清零后再切换，并保留回滚开关。

常用头的最小集合是：Content-Security-Policy、Strict-Transport-Security、X-Content-Type-Options、Referrer-Policy 与 Permissions-Policy。建议把它们纳入部署清单，由平台统一注入而不是各服务自行添加。

从审计到常态化的落地路径

安全响应头的价值在长期一致性，而不是上线当天配置齐全。建议按下面的路径推进，避免一次改动过大。

1. 先做基线扫描：用通用扫描工具或在线检查，把当前缺失与配置不当的头列出来，按影响排序，而不是一次性全改。
2. 纳入代码化的部署模板：把头部配置写进基础设施代码或网关配置，由平台统一注入，避免新服务上线时遗漏。人工在每台服务器上配置的方式无法长期维持。
3. 建立回归检查：在发布流程中加入一次自动化校验，确认关键响应头存在且值符合预期。缺少这一步时，某次重构很可能悄悄把它们移除。
4. 定期评审策略：浏览器标准与业务依赖都在变化，建议每半年复审一次策略，确认是否仍符合当前需求，并评估是否可以收紧。
5. 记录例外：任何为兼容性而放宽的配置都应写明原因、负责人与失效日期，避免临时妥协演变成永久漏洞。

做到这五点，安全头就从“一次性任务”变成持续可控的常规配置，也更容易在审计与合规检查中提供证据。