Skip to main content
All Terms Glossary

Subresource Integrity (SRI)

Definition

Subresource Integrity is a security feature enabling browsers to verify that resources they fetch are delivered without unexpected manipulation. It works by providing a cryptographic hash that a fetched resource must match. This is particularly important for content delivered via CDNs or other third-party hosts.

What SRI is

Subresource Integrity (SRI) is a browser feature that lets you pin a script or stylesheet to a cryptographic hash. You add an integrity attribute containing the expected hash to the script or link tag; the browser downloads the resource, hashes it, and refuses to run it if the hash doesn't match. It guarantees that a file loaded from a CDN or third party is byte-for-byte the version you approved.

What SRI can and cannot do

SRI is excellent against a tampered static file: if an attacker modifies a hosted library, the hash breaks and the browser blocks it. But it only works for resources that don't change. Many third-party scripts are designed to update frequently or are generated per request, and you cannot pin a hash to a moving target. SRI also does nothing once a script legitimately loads and then behaves maliciously at runtime.

SRI plus runtime monitoring

SRI is a strong first layer for the static dependencies you can hash, and PCI DSS references it as one acceptable technique. For the dynamic scripts SRI can't cover, cside adds runtime inspection, analysing what each script does on the page and blocking malicious behaviour, so both your pinned and your unpinnable dependencies are accounted for.

Definition

Why can't I just use SRI on every third-party script?

Because SRI requires a fixed hash, and many third-party scripts change on every load or update without warning. Pinning a hash to them would break the script the moment the vendor ships a new version. SRI fits static, versioned files; it doesn't fit dynamic ones.

Definition

Does SRI meet PCI DSS script requirements on its own?

SRI can satisfy the integrity part of the requirement for static scripts, but PCI DSS 6.4.3 and 11.6.1 also expect you to inventory scripts and monitor for unauthorised changes across all of them, including the dynamic ones SRI cannot pin. It is one tool in the set, not the whole answer.

Got more questions

Talk to a security expert

We answer client-side security questions every day. Bring yours.

Book a demo

Want to walk through this with an engineer?

Thirty minutes, on your own site. Not a slide deck.

We'll show you:

Which third-party scripts are running on your site right now
Where you stand on PCI DSS 6.4.3 and 11.6.1
How much of your traffic is bots and AI agents

Rather just send a question?

Finding open slots…

Real humans only. We'd know.

Having trouble booking? Open scheduler in a new tab

What are you trying to solve?

Tell us in a line and we'll come back with something useful, not a generic pitch.

We usually help with:

Seeing which third-party scripts run on your site
PCI DSS 6.4.3 and 11.6.1 evidence
Bots, AI agents and account takeover

Prefer to just book a time? Pick a slot instead