Subresource integrity on 27 homepages: 5 of 543 cross-origin subresources are checked

FIELD TEST · 2026-09-04 · 27 homepages · one request each · 944 script and stylesheet references

Sample and method: 30 homepages fetched once each on 2026-09-04 with a desktop Chrome user agent, redirects followed, no JavaScript executed, exit node in Osaka, Japan. Three dropped out — stackoverflow.com, medium.com and www.reddit.com each returned 403 — leaving 27.

Across 27 homepages we counted 944 references to external scripts and stylesheets, 543 of them cross-origin. Five carry an integrity attribute, and those five sit on two sites. Subresource integrity is therefore checked on 5 of 543 cross-origin subresources, while crossorigin — the attribute that makes the check possible — appears without integrity 93 times.

How we measured it

One GET per site, desktop Chrome user agent rather than Googlebot, redirects followed, bodies written to disk. In the delivered HTML we parsed every <script src> and every <link rel="stylesheet">, resolved the host of each URL against the final URL of the page, and recorded whether the tag carried integrity, crossorigin, or neither. Protocol-relative //host/path sources were resolved as cross-origin when the host differed.

# The same reading on one of your own pages
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

Two limits. We executed no JavaScript, so a script appended at runtime is invisible here and its integrity attribute, if any, was never counted — the real denominator is larger than 944 by an amount we cannot measure. And an absent integrity is not evidence of an unsafe site: on a page that pins its own CDN and controls both ends, the attribute buys less than it does on a public library.

Who uses subresource integrity, and on what

Two sites, five attributes, three different hash algorithms between them.

MDN describes what the attribute is for in one sentence: it "enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation" (Subresource Integrity, MDN, read 2026-09-04). The consequence of a mismatch is not a warning: "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."

Both adopters are companies that ship code onto other people's sites. That is the only shared trait we can see in a sample of two, and a sample of two supports no conclusion — we are reporting it because it is the whole population here, not because it is a pattern.

The attribute that enables checking is far more common than checking

MDN is explicit that cross-origin SRI needs 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." On this panel, that attribute turns up 93 times on cross-origin tags that carry no integrity at all.

Those tags are not wrong. crossorigin has jobs of its own — error reporting, credential mode, font fetching — and using it does not imply an intention to verify anything. What the count shows is the relative size of two habits on the same 27 pages: the CORS-aware markup is there 93 times, and the hash that would make it a check is there five.

The hash is the check. Everything else is delivery.

Seven sites cannot use it at all, and eighteen choose not to

Seven of the 27 homepages load no cross-origin script or stylesheet whatsoever: nextjs.org, developer.mozilla.org, www.figma.com, news.ycombinator.com, www.wikipedia.org, vercel.com and www.notion.com. For those seven the question does not arise, because everything they load comes from their own origin.

That leaves 20 sites with at least one cross-origin subresource. Two of the 20 check any of it. The other 18 fetch third-party code on every page load and execute whatever comes back.

One more reading, from crossing this count with the other measurement we ran on the same responses. The three sites with the most CORS-marked-but-unverified tags — github.com, www.nytimes.com and slack.com — are all three among the eight sites still sending a deprecated XSS header, counted in X-XSS-Protection across 27 homepages. Eight of 27 send that header, so three out of three landing there is worth noticing and nothing more. We have 27 sites. That is not enough to call it anything.

What this means for your site

This has no search dimension at all. It changes nothing about crawling, indexing or ranking, and this data set contains no ranking information. It is about what runs on your page when a third party's file changes.

1. Pin the libraries you load from a public CDN. Those are the ones where the file can change without your deploy, and the ones where a hash costs you a single attribute.
2. Add crossorigin alongside the hash, not instead of it. On this panel that attribute exists 93 times without a hash, which reads as CORS configuration rather than verification.
3. Do not add it to a URL that changes content behind a stable path. A hash on a file someone updates in place is an outage you scheduled yourself, because the browser refuses the resource rather than warning about it.
4. If everything you load is your own origin, skip this entirely. Seven of these 27 sites are in that position and lose nothing by it.

How those same 625 external scripts are scheduled is measured in async vs defer across 27 homepages, and what a fetch without JavaScript can see of any of them is the subject of can AI crawl JavaScript. To read the tags your own page delivers before anything executes, see how QueryWin reads a page.

Common questions

How did you measure this?

One GET per homepage on 2026-09-04, desktop Chrome user agent, redirects followed, bodies saved. Script and stylesheet tags were parsed from the delivered HTML with a regular expression, hosts compared against the page's final URL, and attributes read per tag. No JavaScript ran. Exit node in Osaka, Japan.

Is subresource integrity worth adding?

On third-party libraries from a shared CDN, the cost is one attribute and the failure mode is loud. On your own origin it adds a hash you now have to keep in sync with every build. We measured adoption, not outcomes, and we have no data on how often a mismatch has ever saved anyone.

Which hash algorithm should I use?

MDN allows sha256, sha384 and sha512. All three appear in the five attributes we found, which tells you the choice is not settled by convention. It does not tell you which is right for you.

Does an integrity attribute affect page speed?

We did not measure that. The browser has to hash the bytes before using them, and none of our numbers say anything about what that costs in practice.

Why do so many tags have crossorigin without integrity?

Because crossorigin is useful on its own — for readable script errors, for credential handling, for fonts. Seeing it does not mean anyone intended to verify a file, and on this panel it usually means they did not.