What is Subresource Integrity (SRI)?
It's the integrity="sha384-…" attribute you add to script and stylesheet tags so the browser mathematically verifies each file against a hash before running it — your defence against a compromised CDN. Flagged as missing on 21 of the 28 real sites in our audit corpus. Check in 30 seconds: right-click your page → View page source → search for integrity=. Your page loads third-party scripts but shows no matches? Any one of those providers can run code on your site, unverified.
The audit checks this on every page it crawls — up to 25 pages — and names every offender in the report.
The definition, in plain English
integrity="sha384-hash" plus crossorigin="anonymous" — that tells the browser: only run this script or stylesheet if its bytes hash to exactly this value. It applies to files you load from third parties (CDNs, public widget hosts): if the CDN is compromised, or the file is tampered with in transit, the hash stops matching and the browser refuses to execute it. Without SRI, every third-party script on your page is a standing invitation: whoever controls that URL controls what code runs on your site, for every visitor, on every page load.
What our engine actually checks
Rule security/sri · severity: warning · flagged on 21 of the 28 real audits behind our statistics page
The audit builds the inventory of cross-origin scripts and stylesheets your pages load — CDN libraries, fonts-as-code, embedded widgets — and checks each one for an integrity attribute. Scripts hosted on your own domain don't need SRI (you control them); the finding is about the files you've delegated to someone else's infrastructure. Findings come back per page with the offending URLs named.
In the corpus: 21 of 28 sites loaded at least one cross-origin script or stylesheet without integrity — typically a jQuery or font library pinned to a public CDN. It's the security finding most sites don't know exists, because the tag works fine and nothing looks wrong.
Why it matters, honestly sized
The cost is the worst kind of security risk: low probability, maximum damage, zero visibility. CDNs and public script hosts are high-value targets — a single compromise at the provider propagates to every site that loads from it, instantly. Injected code can skim card details from checkout forms (the Magecart pattern), harvest passwords, or quietly redirect mobile visitors — and it runs with full access to your page: your cookies, your forms, your logged-in sessions.
You'd never know: the breach would be at the provider, not your server, and your logs would show nothing. SRI is the control that makes that whole scenario fail — a tampered file simply doesn't execute.
The fix, step by step
- Inventory your third-party scripts and stylesheets — view-source on your key templates, or use the report's fix list, which names every cross-origin file per page.
- Pin the version. SRI only works on stable URLs: load
jquery-3.7.1.min.js, neverjquery-latest.js— a self-updating URL breaks your hash the moment the provider ships. - Get the hash and add both attributes: jsDelivr, cdnjs and unpkg display the SRI hash next to each file. The tag becomes:
<script src="https://cdn.example.com/lib-1.2.3.js" integrity="sha384-…" crossorigin="anonymous"></script>. - Leave the un-pinnable alone. Analytics tags, payment SDKs and CAPTCHA widgets update themselves server-side on purpose — they don't support SRI. For those, the equivalent control is a Content-Security-Policy restricting
script-srcto the exact provider origins. - Verify: reload and check the console — a hash mismatch is loudly reported, so a clean console with the attributes present means the protection is live. Re-check hashes whenever you bump a library version.
What the £7.99 report checks — and what it can't
Everything here that can be checked from outside your site is mechanical, and mechanical is checkable. Full disclosure: some of it isn't, and we say which. The report is the full 21-category audit — what it costs and how it compares to doing it yourself are on their own pages.
The mechanical half
Checked across up to 25 pages per audit, with every offending page named and the exact fix spelled out.
- the full inventory of cross-origin scripts and stylesheets per page
- SRI attribute presence on each — with the offending URLs named
- version-pinning: latest-style URLs where a hash can't hold
- the other supply-chain and header defences in the same pass: CSP, HSTS, mixed content
— Not ours to claim
What no report sold from outside your site can do:
- The report maps your exposure and names every unverified file — it can't verify a hash's correctness against the vendor's official build beyond what the CDN publishes, and it doesn't rewrite your templates. The fix list gives your developer the exact attributes per file.
Fair questions, straight answers
Does adding SRI break anything on my site?
Only if the hash is wrong or the file changes under your URL. On a version-pinned URL the content never changes, so the hash holds forever. The failure mode is loud, not silent: the browser refuses the file and logs it to the console — you'd see the breakage immediately in testing, and the fix is simply updating the hash alongside the version bump.
Can I use SRI with Google Analytics, Stripe, or chat widgets?
Generally no, and that's by their design: these SDKs update themselves server-side so providers can patch without every customer redeploying — a fixed hash would break them weekly. SRI is for static versioned libraries you choose to update deliberately. For self-updating SDKs, use a Content-Security-Policy that allow-lists the provider's exact origins instead — that's the same audit's recommendation in the fix list.
What's the difference between SRI and a Content Security Policy?
They're complementary layers on the same problem. SRI says: this exact file, byte-for-byte, or it doesn't run. CSP says: scripts may only load from these origins at all. SRI defends against a trusted host serving something unexpected; CSP defends against loading from an untrusted host in the first place. Sites loading third-party scripts should have both — and in our corpus, most sites have neither.
How do I generate the integrity hash myself?
One command: openssl dgst -sha384 -binary file.js | openssl base64 -A — prefix the output with sha384-. But prefer the hash your CDN publishes (jsDelivr, cdnjs and unpkg all display it next to the file), since it's computed from the exact artifact you're loading and updated with each release.
Find out whose code runs on your pages.
Enter your URL and pay securely — your report PDF lands in your inbox in ~30 minutes,
with every third-party script inventoried and SRI coverage checked page by page.