Step 01
先补低风险、容易验证的基础头
X-Content-Type-Options、Referrer-Policy 和合理的 Permissions-Policy 通常可以先上线。配置后检查 HTML、脚本、样式、图片和下载响应是否都带有预期头，并确认反向代理没有覆盖应用设置。
X-Frame-Options 与 CSP 的 frame-ancestors 需要结合嵌入场景。如果产品确实需要被合作方 iframe 嵌入，不能直接使用完全禁止的策略。
Step 02
HSTS 要确认整个子域范围
HSTS 会让浏览器在有效期内强制使用 HTTPS。加入 includeSubDomains 前，要确认所有仍在使用的子域都能稳定提供 HTTPS，包括旧系统、邮件跳转和临时活动域名。
不要在没有完整盘点时直接加入 preload。错误的长期策略会让无法提供 HTTPS 的子域在浏览器中不可访问，恢复也不会立刻生效。
Step 03
CSP 从真实依赖开始
列出脚本、样式、字体、图片、接口、iframe 和分析服务的实际来源。优先本地托管核心脚本，避免为了省事使用过宽的通配符或 unsafe-eval。
可以先通过报告模式观察违规，再转为强制策略。每次放行都应对应明确业务依赖，并在控制台确认没有阻断登录、支付、验证码或统计上报。
Step 04
用回归测试守住策略
安全头上线后，自动检查关键页面响应头，并用浏览器覆盖首页、登录、表单、报告和移动端等核心路径。第三方服务更新域名或注入脚本时，控制台错误往往是最早信号。
策略文件和允许来源应进入版本管理，变更需要说明业务原因。这样 CSP 不会在数月后重新变成无法解释的白名单集合。
Action Checklist
执行清单
Questions
常见问题
安全头评分低就表示网站已经被攻击吗？
不是。评分反映浏览器防护配置缺口，不代表已经发生入侵，也不能替代应用代码、身份验证和业务逻辑测试。
CSP 应该直接强制上线吗？
复杂站点更适合先盘点依赖并使用报告模式观察违规，再按核心流程逐项收紧，避免阻断登录、支付、验证码和分析服务。
HSTS preload 越早开启越好吗？
不是。必须先确认全部相关子域长期支持 HTTPS，并理解 preload 的长期影响；否则旧系统或临时子域可能在浏览器中无法访问。