What Is Subresource Integrity (SRI)?
Learn how Subresource Integrity hashes protect against tampered CDN scripts and stylesheets in the browser.
Expected Interview Answer
Subresource Integrity is a browser security feature where you attach a cryptographic hash of an expected file to a script or stylesheet tag so the browser refuses to execute that resource if the bytes it actually downloads do not match the hash.
When a page loads a third-party script from a CDN, it is implicitly trusting that CDN not to serve a tampered file, whether through a compromise, a malicious insider, or a man-in-the-middle attack on a misconfigured link. SRI closes that trust gap: you compute a SHA-256, SHA-384, or SHA-512 hash of the exact file you reviewed and add it as an integrity attribute, along with crossorigin='anonymous’ so the browser can perform the check under CORS rules. On load, the browser hashes the bytes it received and compares them to the expected value before executing anything; if they differ, the resource is blocked entirely and an error is reported, rather than silently running altered code. The tradeoff is that the hash is tied to one exact file version, so any legitimate update to the third-party asset requires regenerating and redeploying the new hash, which is why SRI works best for pinned, versioned CDN URLs rather than resources that change without a version bump.
- Detects and blocks tampered CDN-hosted scripts/stylesheets before execution
- Protects against CDN compromise and certain man-in-the-middle tampering
- Fails closed — the browser refuses to run mismatched content rather than warning only
- Encourages pinning exact, reviewed versions of third-party dependencies
AI Mentor Explanation
SRI is like a team refusing to use a shipped bat unless its serial number and factory seal match exactly what the manufacturer certified before dispatch. If the seal is broken or the serial number does not match, the bat is rejected outright rather than risked in a match. The browser does the same thing with a downloaded script: it computes a hash of the actual bytes and compares it against the one the page author certified in advance. Any mismatch means the script never runs at all.
Step-by-Step Explanation
Step 1
Compute the expected hash
The developer generates a SHA-384 (or SHA-256/512) hash of the exact reviewed file.
Step 2
Pin it in the HTML tag
The integrity attribute holds the base64-encoded hash, alongside crossorigin="anonymous".
Step 3
Browser fetches the resource
The script or stylesheet is downloaded from its src/href as normal.
Step 4
Hash comparison gate
Before executing, the browser hashes the received bytes and compares them to the pinned value, blocking on mismatch.
What Interviewer Expects
- Understanding that SRI protects against tampered third-party resources, not general XSS
- Ability to explain the fetch-then-hash-compare mechanism
- Awareness that crossorigin is required for the check to run under CORS
- Knowledge that any legitimate file update requires regenerating the hash
Common Mistakes
- Confusing SRI with Content Security Policy, which is a related but separate mechanism
- Forgetting the crossorigin attribute, which is required for SRI to actually validate
- Assuming SRI protects same-origin scripts you control, rather than third-party ones
- Not realizing an unpinned/auto-updating CDN URL breaks SRI on every legitimate update
Best Answer (HR Friendly)
“Subresource Integrity lets you tell the browser exactly what a third-party script or stylesheet file should look like, using a cryptographic fingerprint. If the file the browser actually downloads from that CDN doesn’t match the fingerprint — say, because it was tampered with — the browser simply refuses to run it. It’s a safeguard against a compromised CDN silently serving malicious code.”
Code Example
<script
src="https://cdn.example.com/lib/analytics.min.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"
></script>
<link
rel="stylesheet"
href="https://cdn.example.com/lib/styles.min.css"
integrity="sha384-9aIt2nRpC12Uk9gS9baDl411NQApFmC26EwAOH8WgZl5MYYxFfc+NcPb1dKGj7Sk"
crossorigin="anonymous"
/>Follow-up Questions
- How does SRI relate to Content Security Policy?
- Why does SRI require the crossorigin attribute?
- What happens if a CDN legitimately updates a file without changing its URL?
- How would you generate an SRI hash in a CI/CD pipeline?
MCQ Practice
1. What does the browser do when a fetched script’s hash does not match its integrity attribute?
SRI fails closed — a hash mismatch means the browser refuses to run the resource at all.
2. What primary threat does Subresource Integrity mitigate?
SRI verifies that fetched third-party files match an expected, pre-certified hash.
3. What attribute must accompany integrity for SRI to validate under CORS?
crossorigin allows the browser to read and verify the response bytes for the integrity check.
Flash Cards
What is Subresource Integrity? — A hash-based check ensuring a fetched script/stylesheet matches an expected, pinned file.
What happens on a hash mismatch? — The browser blocks the resource from executing entirely.
What attribute is required alongside integrity? — crossorigin, so the browser can validate under CORS rules.
Main downside of SRI? — The hash is tied to one exact file version; legitimate updates require regenerating it.