HTTP 安全响应头检查

如果你才刚开始，该从哪里入手

这些响应头的价值并不相等，部署时的风险也不相等。下面按「用最小的弄坏东西的概率换取最多保护」的顺序排列：

最后那一行是最要紧的一行，也是真正需要动手干活的一行。它上面的一切，一个下午就够了。

HSTS，以及它里面那个不可逆的决定

Strict-Transport-Security 告诉浏览器：在接下来的 max-age 秒里，对这个主机一律用 HTTPS，无论如何。它堵上了一个狭窄但真实的缺口：一位访客敲下 example.com，在你的跳转生效之前会先发出一个明文请求，而那个请求是可以被截获的。

Strict-Transport-Security: max-age=31536000; includeSubDomains

includeSubDomains 比它看上去更要紧。没有它，一个通过 HTTP 提供服务的子域名，仍然可以为父域名设置 cookie。有了它，每一个子域名都必须是全 HTTPS，否则就变得不可达——所以加之前先检查一遍。

preload 指令才是那个要好好想想的决定。它会让你的域名被烧进浏览器随版本发布的预加载列表里，于是在第一个请求发生之前，HTTPS 就已经被强制了。它同时也基本上是不可逆的：想要移除，得向列表维护者提出申请，然后等待浏览器版本一路发布出去，那是好几个月。等你确信无疑之后，它非常出色；但随手就加上，是件坏事。

CSP：仅报告模式不是可选项

内容安全策略是这里唯一能阻止被注入的脚本运行的响应头，也是唯一能把你的站点弄下线的那一个。这两个事实来自同一个性质：它限制了什么东西可以被加载。

带上一个收集端点，以仅报告模式部署它，让它在真实流量里跑上几周。你会发现的东西，和你读代码所预期的并不一样——会有一个你忘掉的字体主机，一个支付用的 iframe，还经常有一个在 CDN 边缘被注入的脚本，它在任何源文件里都找不到。最后那一类，正是仅报告模式存在的意义所在。

Content-Security-Policy-Report-Only: default-src 'self';
  script-src 'self'; object-src 'none'; base-uri 'self';
  report-uri /csp-report

有两样东西会抵消掉大部分收益。script-src 里的 'unsafe-inline' 恰恰允许了这条策略当初就是为了阻止的那种被注入的内联脚本——出路是 nonce 或哈希。而 'unsafe-eval' 会重新启用 eval 及其亲戚，某些较老的框架构建版本仍然需要它。本检查器会把这两者标记为「削弱」而不是「缺失」，因为带着它们的策略仍然在做有用的工作；只是它没有在做那件最主要的工作。

那些建议已经过期的响应头

• `X-XSS-Protection`——它控制的浏览器过滤器已经从所有主流浏览器里被移除，而它当年本身就可以被操纵去弄坏页面。在 2026 年，这不是一个该设置的响应头。
• `Expect-CT`——已废弃。证书透明度现在是无条件强制执行的，所以这个响应头什么也不做。
• `Feature-Policy`——已改名为 Permissions-Policy，语法也不同。只有新名字会被认可。
• `Public-Key-Pins`——已从浏览器中移除，而且移除得对。它里面一个失误，就能把你的域名在整个固定期内彻底锁死，且无从挽回。

本工具不检查什么

一个页面，一次响应。它会跟完跳转，读取最终那次响应上的响应头，然后就到此为止。它不会爬取站点，不会执行 JavaScript，不会测试你的 TLS 配置，也不会检查 cookie 的各项标志——而同一个站点上不同的路径，完全可能发送截然不同的响应头，所以检查首页告诉你的只是首页的情况。

专门针对 TLS 配置，Qualys SSL Labs 是那件成名已久的工具，而且很彻底。至于证书本身，这一个会读出一台主机实际出示的是什么。