Understanding Subresource Integrity (SRI) in Web Security
While learning about web security, I came across a security feature that I hadn't paid much attention to before: Subresource Integrity (SRI).
I learned about SRI while reviewing how a website loaded a third-party JavaScript library. This helped me understand why verifying external resources can be an important part of web security.
In this article, I'll explain what SRI is, how it works, and why it matters when websites load JavaScript from external sources.
What Is Subresource Integrity?
Subresource Integrity (SRI) is a browser security feature that allows developers to verify that a resource fetched from an external source matches an expected cryptographic hash.
For example, a website might load a JavaScript library from a third-party server. If that resource is modified unexpectedly, the browser can detect that its contents no longer match the specified hash and refuse to execute it.
Without SRI, the browser does not independently verify the downloaded file against a hash specified by the website.
SRI helps reduce the risk of executing unexpected changes to externally hosted resources.
How Does SRI Work?
SRI uses a cryptographic hash to verify the contents of a resource.
A developer calculates the hash of a trusted version of a JavaScript or CSS file and associates it with the resource in the website's HTML.
When the browser downloads the resource, it checks whether the content matches the expected hash.
If the hash matches, the browser can use the resource.
If the hash does not match, the browser blocks the resource.
This helps prevent modified files from being executed when their contents no longer match the expected version.
Why Is SRI Important?
Many websites depend on third-party JavaScript libraries, frameworks, analytics scripts, and other external resources.
Using external resources can be convenient, but it also introduces a dependency on systems outside the website owner's direct control.
If an externally hosted file is changed unexpectedly, the website may load code that its developers did not intend to use.
SRI provides an additional verification mechanism that can help protect against this type of unexpected modification.
However, SRI is not a complete security solution. It does not replace secure development practices, Content Security Policy (CSP), or careful management of third-party dependencies.
What About Dynamically Loaded JavaScript?
During my review of a website, I noticed that a third-party map library was loaded dynamically using JavaScript.
Dynamically loaded scripts are added to a webpage while it is running, rather than being included directly in the original HTML document.
This matters because a script can load another script at runtime, meaning that reviewing only the initial HTML source may not reveal every external resource used by the page.
SRI can also be applied to dynamically loaded scripts, provided that the expected integrity hash and the necessary cross-origin requirements are correctly configured.
This experience helped me understand why examining how a webpage loads its resources is an important part of reviewing its security.
Does Missing SRI Automatically Mean a Website Is Vulnerable?
No.
The absence of SRI does not automatically prove that a website is exploitable or compromised.
It identifies a missing integrity-verification mechanism for a particular resource. The actual security impact depends on factors such as the resource being loaded, how it is delivered, and the website's other security controls.
It is important to distinguish between a security hardening opportunity and a confirmed vulnerability.
SRI is most useful when the expected contents of a resource can be pinned to a known version. If the resource changes, its hash must be reviewed and updated. Otherwise, legitimate updates may be blocked by the browser.
Key Takeaways
From learning about SRI, I took away a few important points:
SRI allows browsers to verify external scripts and stylesheets against expected cryptographic hashes.
It helps detect unexpected changes to protected resources.
Cross-origin resources require appropriate CORS support.
Dynamically loaded scripts can also use SRI.
Missing SRI does not, by itself, prove that a website is vulnerable.
SRI is one layer of defense, not a replacement for other security controls.
Conclusion
Learning about Subresource Integrity helped me look at third-party JavaScript from a different perspective.
Instead of only asking whether a resource loads correctly, I began to consider how the browser can verify that the resource contains the expected code.
This was a useful lesson in understanding how small configuration choices can contribute to a website's overall security.
As I continue learning web security, I'll document more of the concepts I encounter and the practical lessons I learn along the way.