六个该配的响应头
| 头 | 作用 | 推荐值 |
|---|---|---|
| Strict-Transport-Security | 强制 HTTPS，防降级 | max-age=31536000; includeSubDomains; preload |
| Content-Security-Policy | 限制可加载资源，防 XSS | 按业务逐步收紧 |
| X-Content-Type-Options | 禁止 MIME 嗅探 | nosniff |
| X-Frame-Options / frame-ancestors | 防点击劫持 | DENY 或 SAMEORIGIN |
| Referrer-Policy | 控制来源泄漏 | strict-origin-when-cross-origin |
| Permissions-Policy | 收回不必要的浏览器能力 | 按需禁用相机/麦克风等 |
CSP 别一次写死
先用 Content-Security-Policy-Report-Only 观察误报，再切到真正拦截。尽量用 nonce 或哈希 代替 unsafe-inline；外链脚本要显式列出域名。
两个容易踩的坑
- HSTS 难回退：一旦开启
includeSubDomains+preload，子域名将长期无法走 HTTP，确认所有子域都支持 HTTPS 再开； - 只在边缘节点加：CDN 加了源站没加，攻击者打到源站就绕过了。建议源站与应用层都设置。
怎么验证
用 curl -I https://你的域名 看响应头，或用在线安全头扫描复核。先确保核心业务不受影响，再逐步收紧策略。
CSP 的渐进式落地
CSP 一旦配错会直接打断页面功能，因此必须分阶段推进：
- 先上 Report-Only：用
Content-Security-Policy-Report-Only只上报不拦截，观察一到两周的真实违规； - 收集上报端点：配置
report-to/report-uri并集中分析，区分“必须修”的内联脚本与第三方资源； - 消灭内联脚本：把内联脚本改为外链或用 nonce，
unsafe-inline一旦保留，CSP 的防 XSS 价值会大打折扣； - 逐步收紧指令：先固定
default-src与script-src，再补img-src、connect-src、frame-ancestors； - 最后切强制模式：确认违规日志已清零后再切换，并保留回滚开关。
常用头的最小集合是：Content-Security-Policy、Strict-Transport-Security、X-Content-Type-Options、Referrer-Policy 与 Permissions-Policy。建议把它们纳入部署清单，由平台统一注入而不是各服务自行添加。
从审计到常态化的落地路径
安全响应头的价值在长期一致性，而不是上线当天配置齐全。建议按下面的路径推进，避免一次改动过大。
- 先做基线扫描：用通用扫描工具或在线检查，把当前缺失与配置不当的头列出来，按影响排序，而不是一次性全改。
- 纳入代码化的部署模板：把头部配置写进基础设施代码或网关配置，由平台统一注入，避免新服务上线时遗漏。人工在每台服务器上配置的方式无法长期维持。
- 建立回归检查：在发布流程中加入一次自动化校验，确认关键响应头存在且值符合预期。缺少这一步时，某次重构很可能悄悄把它们移除。
- 定期评审策略：浏览器标准与业务依赖都在变化，建议每半年复审一次策略，确认是否仍符合当前需求，并评估是否可以收紧。
- 记录例外：任何为兼容性而放宽的配置都应写明原因、负责人与失效日期，避免临时妥协演变成永久漏洞。
做到这五点，安全头就从“一次性任务”变成持续可控的常规配置，也更容易在审计与合规检查中提供证据。