最常见的 10 个安全响应头错误（以及如何修复）
安全响应头是你能部署的最省成本的加固手段，也是最容易在细节上出错的。这里是扫描器最常标记的十个错误，并给出每个的确切修复方法。
HTTP 响应头是一种少见的安全控制：只需几行配置，就能立刻保护每一位访问者。这也正是它常被设错的原因：它易于复制粘贴，却难以测试。以下是扫描结果中反复出现的十个问题。
1. 没有 HSTS（或 HSTS 缺少 preload）
没有 Strict-Transport-Security，一次明文请求就可能在跳转到 HTTPS 之前被拦截。设置较长的 max-age 并包含子域：
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload只有当每个子域都仅支持 HTTPS 时才加 preload——它很难快速撤销。
2. 允许 unsafe-inline 的 Content-Security-Policy
script-src 'unsafe-inline' 会重新打开 CSP 本应堵上的那个 XSS 缺口。改用 nonce 或 hash：
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; object-src 'none'; base-uri 'self'3. 永远停留在 report-only 模式
Content-Security-Policy-Report-Only 是给上线过渡阶段用的。很多网站一放就是几个月，只收集报告却不实际拦截。用 report-only 找出违规，待它安静下来后再切到强制执行的响应头。
4. 用 X-Frame-Options 而非 frame-ancestors
X-Frame-Options 已是旧方案，无法表达白名单。优先使用现代浏览器认可的 CSP 指令：
Content-Security-Policy: frame-ancestors 'self'5. 缺少 X-Content-Type-Options
没有 X-Content-Type-Options: nosniff，浏览器可能对响应做 MIME 嗅探，把你当作文本返回的内容当成脚本执行。这只是一个响应头，没有任何副作用——务必设置。
6. 危险或缺失的 Referrer-Policy
默认设置会把完整 URL（包括查询串中的令牌）泄露给第三方。一个安全、兼容性良好的选择：
Referrer-Policy: strict-origin-when-cross-origin7. Permissions-Policy 停留在浏览器默认值
如果你的应用不使用摄像头、麦克风或地理位置，就明确声明，这样被攻陷的脚本也无法使用：
Permissions-Policy: camera=(), microphone=(), geolocation=()8. 只给 HTML 设响应头，却漏掉 API
前端框架设置的响应头常常漏掉 API 路由、重定向和错误页。扫描器会直接测试这些路径。把安全响应头设在边缘层——反向代理、CDN 或平台中间件——这样覆盖才一致。
9. 多层设置导致响应头冲突
当你的应用和 CDN 都设置了 Content-Security-Policy，浏览器可能看到两个头并取其*交集*，悄无声息地破坏功能。确定一个权威层，删掉重复项。
10. 缓存了敏感响应
需要认证的页面以及含个人数据的 API 响应，不应被共享代理缓存：
Cache-Control: no-store用一次重新扫描来确认
响应头之间会相互影响，所以要小批量修改，每改一批就重新扫描一次。如果你刚开始看报告，先读如何读懂网站安全扫描报告；关于这些响应头之下的传输层，参见让网站面临风险的 SSL/TLS 配置错误。完整的响应头检查会在每次扫描时运行——参见功能页上的全部检查项。