网站安全响应头怎么补，才不会把页面功能弄坏

Step 01

先补低风险、容易验证的基础头

X-Content-Type-Options、Referrer-Policy 和合理的 Permissions-Policy 通常可以先上线。配置后检查 HTML、脚本、样式、图片和下载响应是否都带有预期头，并确认反向代理没有覆盖应用设置。

X-Frame-Options 与 CSP 的 frame-ancestors 需要结合嵌入场景。如果产品确实需要被合作方 iframe 嵌入，不能直接使用完全禁止的策略。

Step 02

HSTS 会让浏览器在有效期内强制使用 HTTPS。加入 includeSubDomains 前，要确认所有仍在使用的子域都能稳定提供 HTTPS，包括旧系统、邮件跳转和临时活动域名。

不要在没有完整盘点时直接加入 preload。错误的长期策略会让无法提供 HTTPS 的子域在浏览器中不可访问，恢复也不会立刻生效。

Step 03

列出脚本、样式、字体、图片、接口、iframe 和分析服务的实际来源。优先本地托管核心脚本，避免为了省事使用过宽的通配符或 unsafe-eval。

可以先通过报告模式观察违规，再转为强制策略。每次放行都应对应明确业务依赖，并在控制台确认没有阻断登录、支付、验证码或统计上报。

Step 04

安全头上线后，自动检查关键页面响应头，并用浏览器覆盖首页、登录、表单、报告和移动端等核心路径。第三方服务更新域名或注入脚本时，控制台错误往往是最早信号。

策略文件和允许来源应进入版本管理，变更需要说明业务原因。这样 CSP 不会在数月后重新变成无法解释的白名单集合。

Action Checklist