x-xss-protection 实测 27 个首页：8 个还在发，其中 5 个发它是为了把这个功能关掉

实测 · 2026-09-04 · 27 个首页 · 每站一次请求 · 一个已被废弃的安全响应头

样本 / 口径：2026-09-04 当天对 30 个首页各发一次 GET，桌面 Chrome UA，跟随跳转，不执行 JavaScript，出口在日本大阪。stackoverflow.com、medium.com、www.reddit.com 三个站返回 403，剔除后纳入 27 个。

27 个首页里还有 8 个在发 x-xss-protection —— MDN 给这个头同时标了「已废弃」和「非标准」。8 个里有 5 个发的是 0，也就是把这个功能关掉。另外 3 个发的是 1; mode=block，正是 MDN 挂了安全警告的那个方向；而这 3 个站同时都在发 Content-Security-Policy，也就是文档里让你改用的那个。

怎么测的

每个站一次 GET，用桌面 Chrome UA 而不是 Googlebot，跟随跳转，全部响应头小写后记录。x-xss-protection 的取值逐字读出，再和同一条响应上的 content-security-policy 做交叉。数的是站数，不是头的条数。

# 在你自己的页面上读同样两处
curl -sIL -A 'Mozilla/5.0' https://example.com/ \
  | grep -iE '^(x-xss-protection|content-security-policy):'

# 两行都回来，说明老的和替代它的那个你在同时发

局限还是老几条。只测首页、每站一次；这里没有的头，完全可能发在我们没碰过的应用子域名上。另外我们没有测任何浏览器行为 —— 这份测量说明不了今天某个浏览器拿这些取值会做什么，只说明服务器说了什么。

那 8 个站发的到底是什么

两种取值，方向正好相反。

MDN 给了四个可能的取值：0 是「Disables XSS filtering」；1 打开过滤，「the browser will sanitize the page」；1; mode=block 则是「the browser will prevent rendering of the page if an attack is detected」；还有一个 1; report=<reporting-URI> 标着仅 Chromium 支持（X-XSS-Protection，MDN，2026-09-04 访问）。中间这两个取值在本面板上一次都没出现。没有人做净化，也没有人做上报。

8 个里有 5 个发 x-xss-protection 是为了把它关掉

这就是这次结果的形状，值得直说：2026-09-04 这一天，在这 27 个首页上，人们拿这个头做得最多的一件事是发 0。5 个站花一个响应头去关掉一个功能，3 个站花一个去打开它，19 个站一个字都不花，拿到的是浏览器的默认行为。

MDN 的警告解释了为什么发 0 是一种立场而不是配错：「Even though this feature can protect users of older web browsers that don't support CSP, in some cases, X-XSS-Protection can create XSS vulnerabilities in otherwise safe websites.」同一页的结尾给了建议：「It is recommended that you use Content-Security-Policy instead of XSS filtering.」

一个值为 0 的响应头不是配置，是在回答一份扫描报告。

为什么这 5 个站选择显式关掉、而不是把那一行删了，一次响应看不出来。为了回应一份自动化安全报告是一种说得通的理由，覆盖平台或反向代理替你设的默认值是另一种。我们没有去问任何人，也不打算在这上面继续猜。

安全扫描要求你发这个头，配置里那一行该怎么办

这一节是给拿着扫描报告的人的。中文侧搜这个词的人，下拉里自带 nginx、spring boot、owasp 三条 —— 多数不是在读规范，是在配置文件里看见了那一行，或者在一份合规清单上看见了这一条。

顺序只有三步。先用上面那条 curl 看你实际发的是什么，再去配置里找那一行，最后决定删还是改。反向代理里那一行通常长这样，框架的安全模块也可能替你加了同样的头，所以两处都要找：

# 反向代理配置里常见的写法，先搜这个字符串
add_header X-XSS-Protection "1; mode=block" always;

# 框架也可能替你加，实际发了什么以 curl 的结果为准
curl -sI https://example.com/ | grep -i x-xss-protection

删掉那一行和把它改成 0，按文档描述落到的是同一种浏览器行为，区别只在扫描器能不能读到一个值。真要给扫描器一个交代，本面板上 5 个站给的答案就是 0。

还开着的那 3 个站，替代品早就在发了

把两个头放在同样 27 条响应上交叉一遍，是这次测量里最锋利的一处读数。

三个还把老过滤器开着的站，全都已经在发 MDN 让你改用的那个头。这不算自相矛盾 —— 一个老头压在新头下面躺好几年，没人会注意到 —— 但它确实说明「留着它」的理由比看上去薄：这个头有文档支撑的收益是给不支持 CSP 的旧浏览器的，而这三个站对所有人都在发 CSP。

整个面板上 Content-Security-Policy 出现在 27 条响应里的 17 条上，是它所替代的那个头的五倍还多。而一条 CSP 也可能把你本来想让人抓到的东西挡掉，那是另一个问题，写在 content-security-policy 会不会挡住抓取。

这对你意味着什么

这件事和搜索没有任何关系。它不改变抓取和收录，这份数据里也没有排名信息。它的价值是一个维护信号：响应里出现一个已废弃的头，通常是某个很久没人打开过的配置文件露出来的那一角。

1. 先看自己发了什么，再决定别的。一条 curl -sI 就够，而这里大约七成的站什么都不发。
2. 发 1; mode=block 的，读一遍 MDN 那条警告，再确认自己是不是也在发 CSP。本面板上处在这个位置的三个站，三个都在发。
3. 扫描器要这个头，0 就是这里五个站给出的答案。整行删掉落到的是同一种浏览器行为。
4. 新站不要加这个头。它已废弃、非标准，而且它自己的文档指向了别处。

同一族里没有被废弃的那个头，量在 x-content-type-options 实测 27 个首页；同一批响应还被用来数第三方代码的校验，写在 subresource integrity 实测 27 个首页。想一次看完自己页面返回的全部响应头，可以 看看 QueryWin 是怎么读一个页面的。

常见问题

你们是怎么测的

2026-09-04 当天，30 个首页各发一次 GET，桌面 Chrome UA，跟随跳转，全部响应头小写后记录。取值逐字读出，再与同一条响应上的 Content-Security-Policy 做交叉。数的是站数。出口在日本大阪。

这个头是删掉好还是设成 0 好

按文档描述，两种落到的浏览器行为是一样的。这里 5 个站选了显式的 0。如果你的流程里没有任何东西在要这个头，删掉那一行以后少一件要解释的事。

1; mode=block 危险吗

MDN 警告这个头在某些情况下会给本来安全的站引入 XSS 漏洞，但没有点名具体取值。我们没有复现过任何一例，这里也没有我们自己的测量，所以转述完就停在这儿。

它影响 SEO 吗

这里没有任何证据说影响。这份测量不含排名数据，而这个头作用在浏览器怎么渲染页面上，不作用在爬虫收到什么。

为什么 19 个站什么都不发

是决定还是遗漏，我们分不出来，一次响应也永远分不出来。这个数字能说明的是：在这个面板上，发这个头已经是少数派做法。