响应头的配置示例随处可见。问题在于大多数已经停止更新了。照抄几年前正确的清单，就会带进一些已经失去作用的响应头——还有一个可能反而有害的。
① 今天值得设置的6个
我们的安全响应头检测工具按这6个评估。已废弃的响应头被有意排除在外。
- Content-Security-Policy
- 声明脚本和资源可以从哪里加载。是缩小 XSS 能做的事的核心控制。它的
frame-ancestors也管理嵌入 - Strict-Transport-Security
- 告诉浏览器以后一律用 HTTPS 访问，堵住第一次的明文请求（
max-age加includeSubDomains） - X-Frame-Options
- 拒绝被其他网站嵌入框架——防御点击劫持。实际中与 CSP 的
frame-ancestors一起设置 - X-Content-Type-Options
nosniff。阻止浏览器根据内容猜测类型，减少上传的文件被当作不该是的东西来解析的事故- Referrer-Policy
- 限制向外传递的来源页信息，减少URL 中所含内容的泄露（前提是你本来就不把机密放进 URL）
- Permissions-Policy
- 默认禁用浏览器功能——摄像头、麦克风、地理位置。不用的就关掉
顺序很重要：先加不会弄坏东西的
X-Content-Type-Options、X-Frame-Options、Referrer-Policy 和 Permissions-Policy 可靠且不容易影响页面显示，可以先加。Strict-Transport-Security 要等所有路径都能正常使用 HTTPS 后再加——浏览器会记住它，要撤回很麻烦。
CSP 最后加，并且要逐步引入。它影响的功能最多，一步到位地收紧会弄坏正常功能。请用 CSP 生成器逐步搭建。
② 已经失去作用的
Expect-CT：自2021年6月起基本已过时
MDN 把这个响应头标为 Deprecated，并说明只有 Google Chrome 和其他基于 Chromium 的浏览器实现过它，而 Chromium 从107版起废弃了这个响应头，因为 Chromium 现在默认强制执行 CT。同一页面的注释还写道：“Expect-CT 自2021年6月起基本已过时”。
也就是说，浏览器已经默认这样做了，网站不再需要发出指示。没有理由在新项目中加上它。
③ 现在反而可能有害的
X-XSS-Protection：已废弃、非标准，还可能制造 XSS
MDN 在这个响应头上同时标有 Deprecated 和 Non-standard，并附有警告：“虽然这个功能能保护不支持 CSP 的旧浏览器用户，但在某些情况下，X-XSS-Protection 可能在原本安全的网站上制造 XSS 漏洞。”
它的建议毫不含糊：“建议使用 Content-Security-Policy 代替 XSS 过滤。”
这是反驳“响应头越多越好”的决定性例子。出于好意加上的设置，在特定条件下可能变成攻击面。没在发送就不要加；已经在发送就计划删掉。底层缺陷见什么是 XSS。
过时清单的样子
CSP、HSTS、X-Frame-Options、nosniff——再加上
X-XSS-Protection: 1; mode=block
Expect-CT: max-age=…
Public-Key-Pins: …
清单更长，有些检测工具甚至可能给出更高的分数。但对当前的浏览器来说，多出来的这些项要么不起作用，要么可能有害。
现在的做法
以 CSP 为中心，其他5个作为辅助。
已废弃的响应头不加，已有的就删掉。把精力花在 CSP 的质量上——具体说就是去掉了多少 'unsafe-inline'——比把清单加长带来的实际防御要多得多。
前提：响应头修不好漏洞本身
应用的缺陷（XSS、缺少授权检查、上传）
加多少响应头都消除不了这些
↓ 一旦发生
响应头管的是
数据能发往哪里 · 页面能否被嵌入 · 是否允许明文 ＝ 限制扩散
给有 XSS 缺陷的网站加上 CSP，并不会消除 XSS；只是缩小了能利用它做的事。所以顺序是：先修好应用的缺陷，再把响应头作为又一道防线叠加上去。反过来也成立——响应头拿满分，并不能证明网站是安全的。
检查自己的网站
测量实际返回的内容
看响应，而不是配置文件。反向代理、CDN、框架和应用本身都会添加或覆盖响应头，所以配置的和实际发出的并不总是一样。我们的响应头检测工具可以直接测量一个 URL。
在结果中查找已废弃的响应头
如果返回了 X-XSS-Protection 或 Expect-CT，计划把它们删掉。尤其是前者——如上所述，文档写明它可能制造漏洞。
加上不会弄坏东西的4个
X-Content-Type-Options: nosniff、X-Frame-Options: DENY、Referrer-Policy: strict-origin-when-cross-origin，以及关闭不用功能的 Permissions-Policy。可靠，且不容易影响页面显示。
等 HTTPS 完全正常后再加 HSTS
Strict-Transport-Security 会被浏览器记住，在 HTTPS 还不稳定时启用，恢复起来会很麻烦。先确认所有路径都能提供 HTTPS。证书的基础知识见什么是 Let's Encrypt。
本站的看法：照抄的配置，来源有多旧就决定了有多安全
安全响应头是最典型的复制粘贴式配置，正因如此，来源有多旧决定了结果有多安全。本文提到的两个响应头都曾经是正确的。X-XSS-Protection 更进一步：当年的推荐，成了今天的警告。
我们的立场是把响应头配置当作需要不时回头检查的设置，而不是做一次就完成的任务——也不要以检测工具的分数为目标，因为加上已废弃的响应头也可能让分数上升。把时间花在 CSP 的质量上，而不是清单的长度上。
出处（一手资料）
- MDN Web Docs「X-XSS-Protection」— developer.mozilla.org（Deprecated 和 Non-standard 标记、可能在原本安全的网站上制造 XSS 漏洞的警告、以及改用 CSP 的建议）
- MDN Web Docs「Expect-CT」— developer.mozilla.org（Deprecated 标记、Chromium 107 废弃它及其理由、自2021年6月起基本已过时的注释）
两者均于2026年9月5日确认。
接下来阅读
FAQ
Q应该设置 X-XSS-Protection 吗？
不应该。MDN 把这个响应头同时标为 Deprecated（已废弃）和 Non-standard（非标准），并警告：虽然它能保护不支持 CSP 的旧浏览器用户，但在某些情况下，X-XSS-Protection 可能在原本安全的网站上制造 XSS 漏洞。它的建议很明确：用 Content-Security-Policy 代替 XSS 过滤。没在发送就不要加；已经在发送就计划删掉。
QExpect-CT 还需要吗？
不需要。MDN 把它标为 Deprecated，并说明只有 Google Chrome 和其他基于 Chromium 的浏览器实现过它，而 Chromium 从107版起废弃了这个响应头，因为 Chromium 现在默认强制执行证书透明度（Certificate Transparency）。同一页面的注释写明，这个响应头自2021年6月起基本已过时。没有理由在新项目中加上它。
Q那应该设置哪些？
我们的响应头检测工具所评估的6个是实用的起点：Content-Security-Policy、Strict-Transport-Security、X-Frame-Options、X-Content-Type-Options、Referrer-Policy 和 Permissions-Policy。已废弃的响应头被有意排除在外。顺序上，先加可靠、不容易弄坏东西的（nosniff、X-Frame-Options），CSP 影响的功能最多，要逐步引入。
Q所有响应头都设置了，网站就安全了吗？
不是。响应头修不好应用里的漏洞，它们限制的是损害扩散的范围。给有 XSS 缺陷的网站加上 CSP，并不会消除 XSS——只是缩小了能利用它做的事。先修好应用的缺陷，再把响应头作为又一道防线叠加上去。反过来也一样：响应头检测拿满分，并不能证明网站是安全的。