What it protects, what it doesn’t, and why most teams use it incorrectly
Subresource Integrity (SRI) is often described as the solution to third-party JavaScript risk.
In reality, SRI is a narrow but valuable control that is frequently misunderstood — and dangerously over-trusted.
This deep dive explains how SRI actually works, where it meaningfully helps, and why it must be paired with runtime visibility to protect JWTs, sessions, and sensitive browser flows.
What SRI Is Designed to Do
SRI allows the browser to verify that a fetched resource has not changed since it was approved.
Example:
<script src="https://cdn.vendor.com/lib.js"
integrity="sha384-abc123..."
crossorigin="anonymous"></script>
If the script content changes — even by one byte — the browser refuses to execute it.
This is powerful.
But it is also very limited.
What SRI Protects Well
SRI is effective when:
- Scripts are static
- URLs are versioned
- Content never changes
- Updates are intentional and reviewed
In these cases, SRI prevents:
- CDN compromise
- Silent script replacement
- Cache poisoning
- Accidental drift
It answers one question very well:
“Is this exact file still the same?”
Where SRI Falls Apart in Real Applications
Modern applications rarely meet SRI’s assumptions.
1. Most Third-Party Scripts Are Dynamic
Analytics, tag managers, chat widgets, A/B testing tools — all change frequently.
This forces teams to:
- Remove SRI
- Disable integrity checks
- Or stop using the tool
Guess which option usually wins.
2. SRI Does Not Detect Malicious Logic in Approved Code
If a vendor:
- Pushes a malicious update intentionally or accidentally
- Ships risky new behavior
- Changes execution paths
SRI passes — because the hash matches.
Integrity ≠ safety.
3. SRI Does Nothing for Inline or Injected Code
SRI:
- Does not protect inline scripts
- Does not see dynamically injected code
- Does not stop DOM-based attacks
- Does not detect runtime manipulation
Most real-world attacks happen after the script loads.
4. SRI Breaks at Scale
Managing hashes across:
- Multiple environments
- Multiple vendors
- Frequent releases
Quickly becomes operationally unmanageable — especially without automation.
The False Sense of Security Problem
Organizations often believe:
“We use SRI, so third-party risk is handled.”
In practice:
- SRI is enabled on a few static libraries
- Disabled everywhere else
- Never reviewed after deployment
This creates partial coverage and false confidence.
Attackers exploit the unprotected majority.
SRI vs Modern Client-Side Attacks
| Attack Type | Does SRI Help? |
|---|---|
| CDN file replacement | ✅ Yes |
| Compromised vendor pushing new version | ❌ No |
| DOM-based XSS | ❌ No |
| Script injection via tag manager | ❌ No |
| Browser extension injection | ❌ No |
| JWT theft via runtime hooks | ❌ No |
SRI protects files — not execution.
Where SRI Does Belong
SRI is best used for:
- Framework libraries
- Immutable vendor bundles
- Rarely changed dependencies
- Critical bootstrap scripts
It should be treated as:
A guardrail, not a security system.
Why Auditors Still Like SRI
Auditors view SRI as:
- A positive compensating control
- Evidence of supply-chain awareness
- Part of a layered defense strategy
But auditors increasingly ask:
- How do you handle dynamic scripts?
- How do you detect runtime changes?
- What happens when SRI isn’t applicable?
SRI alone does not answer these.
How BreachFin Complements SRI
SRI answers:
“Did the file change?”
BreachFin answers:
“Did the behavior change?”
BreachFin provides:
- Runtime visibility into script execution
- Detection of behavior drift in approved scripts
- Alerts when trusted code starts acting differently
- Evidence when integrity ≠ safety
Together, SRI + runtime monitoring form a complete control, not a partial one.
A Practical Modern Strategy
Effective client-side protection uses:
- SRI for immutable resources
- CSP to restrict sources
- Trusted Types to protect DOM sinks
- Runtime monitoring to detect abuse
No single control is sufficient on its own.
Final Takeaway
Subresource Integrity is valuable — but narrow.
It ensures files haven’t changed.
It does not ensure behavior is safe.
If your security strategy assumes:
“Integrity equals security”
Then the most common client-side attacks will bypass you entirely.
Modern browser security requires knowing what executes, not just what loads.
That distinction is exactly where BreachFin provides value.
