subresource integrity 实测 27 个首页：543 条跨源资源里只有 5 条被校验

实测 · 2026-09-04 · 27 个首页 · 每站一次请求 · 944 条脚本与样式表引用

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

27 个首页上一共数到 944 条外部脚本与样式表引用，其中 543 条是跨源的。带 integrity 属性的有 5 条，集中在 2 个站上。也就是说 subresource integrity 在 543 条跨源资源里只校验了 5 条；而让这项校验成为可能的 crossorigin 属性，单独出现了 93 次。

怎么测的

每个站一次 GET，用桌面 Chrome UA 而不是 Googlebot，跟随跳转，正文全部落盘。在投递 HTML 里解析每一个 <script src> 和每一个 <link rel="stylesheet">，把每条 URL 的 host 和页面最终 URL 的 host 比对，再记录这个标签带的是 integrity、crossorigin，还是两个都没有。协议相对写法 //host/path 按 host 比对，不同就算跨源。

# 在你自己的页面上读同样几处
curl -sL -A 'Mozilla/5.0' https://example.com/ > page.html
grep -oE '<script [^>]*src="[^"]+"[^>]*' page.html | wc -l
grep -c 'integrity="sha' page.html
grep -oE 'crossorigin[^>]*' page.html | wc -l

两条局限。我们不执行 JavaScript，运行时才插进去的脚本在这里看不见，它身上有没有 integrity 也没被数进去 —— 真实分母比 944 大，大多少我们测不出来。另外，没有 integrity 不等于这个站不安全：一个只加载自家 CDN、两头都归自己管的页面，加这个属性买到的东西比在公共库上少得多。

安全报告里那条 SRI not implemented，先分清自己在不在这一类

出海站在做支付方安全评估、客户安全问卷或者一次渗透测试之后，很容易收到一条「SRI not implemented」。先看一个数：这 27 个首页里，有 7 个根本加载不了任何跨源脚本或样式表 —— nextjs.org、developer.mozilla.org、www.figma.com、news.ycombinator.com、www.wikipedia.org、vercel.com、www.notion.com。它们的东西全来自自己的源站，这条建议对它们不成立。

剩下 20 个站有至少一条跨源资源。20 个里有 2 个校验了其中一部分，另外 18 个每次打开页面都在拉第三方代码，拉到什么执行什么。

所以这条建议该不该修，取决于你落在哪一行。第一行不用管，第二行值得挑公共 CDN 上的那几条来做，第三行已经在做了。

用了 subresource integrity 的两个站，各用在什么上

两个站、五条属性，三种哈希算法都出现过。

MDN 用一句话说清了这个属性的用途：它「enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation」（Subresource Integrity，MDN，2026-09-04 访问）。对不上的后果不是一条警告：「If the actual value does not match any of the specified values, then the browser will refuse to load the resource and return a network error.」

两个采用者都是把代码发到别人站上去的公司。这是我们在两个样本里唯一看得出的共同点，而两个样本支撑不了任何结论 —— 写出来是因为它就是这里的全部总体，不是因为它是一条规律。

让校验成为可能的那个属性，比校验本身常见得多

MDN 写明了跨源做 SRI 必须走 CORS：「Cross-origin requests that use subresource integrity must use the Cross-Origin Resource Sharing (CORS) protocol. You must include the crossorigin attribute in your markup.」而在这个面板上，这个属性出现在 93 个跨源标签上，那些标签一个 integrity 都没有。

这些标签没有写错。crossorigin 本身就有它自己的用处 —— 让脚本错误可读、控制凭据模式、加载字体 —— 用它并不代表谁打算校验什么。这个数字说的只是同样 27 个页面上两种习惯的相对规模：懂 CORS 的写法出现了 93 次，能让它变成一次校验的那个哈希出现了 5 次。

哈希才是校验，其余都只是投递。

还有一处读法来自同一批响应的另一次统计。crossorigin 却不带 integrity 最多的三个站 —— github.com、www.nytimes.com、slack.com —— 三个全部落在「仍在发一个已废弃 XSS 响应头」的那 8 个站里，数在 x-xss-protection 实测 27 个首页。27 个站里有 8 个在发那个头，三个全中值得记一笔，也就到此为止。面板只有 27 个站，这个数说明不了什么。

这对你意味着什么

这件事和搜索没有任何关系。它不改变抓取、收录和排名，这份数据里也没有排名信息。它管的是：当第三方那个文件变了，你的页面上会跑起什么。

1. 从公共 CDN 加载的库先钉住。那些文件可以在你不发版的情况下改掉，而钉住它只需要一个属性。
2. crossorigin 要和哈希一起加，不是拿它代替哈希。这个面板上它有 93 次是单独出现的，那读起来是 CORS 配置，不是校验。
3. 别把它加在「路径不变、内容会变」的地址上。在一个会被原地更新的文件上写哈希，等于给自己排了一次故障 —— 浏览器是拒绝加载，不是提醒你。
4. 加载的全是自家源站，就整个跳过这一节。这 27 个里有 7 个正是这样，什么也没损失。

同样这 625 个外链脚本的加载时机，量在 async defer 实测 27 个首页；一次不执行 JavaScript 的抓取能看到它们多少，写在 AI 爬虫会执行 JavaScript 吗。想看自己的页面在任何脚本运行之前投递了哪些标签，可以 看看 QueryWin 是怎么读一个页面的。

常见问题

你们是怎么测的

2026-09-04 当天，30 个首页各发一次 GET，桌面 Chrome UA，跟随跳转，正文落盘。脚本和样式表标签用正则从投递 HTML 里解析出来，host 与页面最终 URL 比对，属性逐标签读。全程不执行 JavaScript。出口在日本大阪。

安全扫描报的 SRI not implemented 一定要修吗

先看你在上面那张分组表的哪一行。没有跨源资源的那一行不用修；有跨源的，优先修从公共 CDN 拉的那几条。我们没有任何数据能说明修完之后风险降了多少。

该用哪种哈希算法

MDN 允许 sha256、sha384、sha512。我们找到的五条属性里三种都出现了，这说明业界还没形成惯例，但它答不了你该选哪一种。

加了 integrity 会不会拖慢页面

我们没测。浏览器要先把字节算一遍哈希才能用，而我们的数字里没有一个能说明这在实际中要花多少。

为什么那么多标签只有 crossorigin 没有 integrity

因为 crossorigin 本身就有用 —— 拿到可读的脚本报错、处理凭据、加载字体。看到它不代表谁打算校验一个文件，而在这个面板上，多半是没打算。