Loading third-party libraries directly from public CDNs is standard practice in web development. Whether pulling in a CSS framework, a charting library, or analytics helpers, grabbing a minified bundle from a fast global network saves bandwidth and build complexity.
However, the moment you insert an external <script src="https://cdn.example.com/lib.min.js"> tag into your HTML, you grant that external domain arbitrary JavaScript execution inside your application's security context. If that CDN suffers a compromise, DNS hijacking, or account takeover—as seen in major supply chain incidents like the Polyfill.io domain hijacking—attackers can inject credit card skimmers, session hijackers, or cryptominers directly into your users' browsers.
This is where Subresource Integrity (SRI) becomes essential.
How Subresource Integrity Actually Works
Subresource Integrity is a W3C security standard that enables browsers to verify that fetched resources (JavaScript files and CSS stylesheets) match an exact cryptographic digest before they execute.
When a browser encounters a <script> or <link> tag with an integrity attribute, it fetches the file, calculates its cryptographic hash, and compares the resulting digest against the provided value. If even a single byte differs—whether due to malicious tampering, CDN corruption, or an unexpected upstream update—the browser instantly blocks the script from executing and throws a network security error in the developer console.
<script
src="https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.21/lodash.min.js"
integrity="sha384-6t7sJtKjJ6kZ7v9K2m9q+8wZ6B8XgM4bZ4v4+9Z6B8XgM4bZ4v4+9Z6B8XgM4bZ4"
crossorigin="anonymous">
</script>
Anatomy of an SRI Hash: Binary Digests vs. Hex Strings
A common mistake when generating SRI hashes manually is attempting to paste a standard hexadecimal SHA-256 string into the integrity attribute. Browsers will reject this immediately.
An SRI attribute requires two components separated by a hyphen:
-
Algorithm prefix:
sha256,sha384, orsha512(W3C strongly recommends SHA-384 for modern 64-bit architectures). - Base64-encoded binary digest: The raw binary output of the hash function, encoded in Base64 (not hexadecimal).
You can generate a valid SRI hash via OpenSSL in your terminal:
# Fetch the file, calculate raw binary SHA-384, and encode in Base64
curl -s https://cdn.jsdelivr.net/npm/lodash@4.17.21/lodash.min.js \
| openssl dgst -sha384 -binary \
| openssl base64 -A
If you need to quickly generate hashes and ready-to-use HTML tags without opening a terminal or piping binary streams, the Nutilz SRI Hash Generator computes SHA-256, SHA-384, and SHA-512 hashes directly in your browser using the native Web Crypto API (crypto.subtle.digest).
4 Production Edge Cases That Break SRI
Deploying SRI in production often surfaces subtle browser behaviors that cause valid scripts to fail silently or trigger unexpected CORS errors.
1. Missing crossorigin="anonymous"
Browsers require Cross-Origin Resource Sharing (CORS) authorization before validating SRI on external domains. Without crossorigin="anonymous", the browser blocks script execution because cross-origin response bodies cannot be inspected without explicit CORS headers (Access-Control-Allow-Origin: *). Always pair integrity with crossorigin="anonymous".
2. Compression & Payload Hashing
SRI hashes are computed strictly over the uncompressed response payload. If your build system or deployment pipeline hashes a pre-compressed gzip or Brotli buffer instead of the decompressed text, the browser will decompress the stream, hash the plaintext, and reject the mismatch.
3. Dynamic / Floating CDN URLs
Using floating version tags (such as @latest or major-version ranges like /v2/) will inevitably break your site when the vendor publishes a minor patch. SRI requires immutable, version-pinned URLs.
4. Multiple Hash Algorithms
You can provide multiple space-separated hashes to support different client capabilities:
<script
src="https://cdn.example.com/app.js"
integrity="sha256-abc... sha384-def... sha512-ghi..."
crossorigin="anonymous">
</script>
When multiple algorithms are specified, modern browsers evaluate the strongest supported algorithm (e.g., preferring SHA-512 over SHA-256) and ignore the weaker ones.
Conclusion
Third-party CDNs offer speed and convenience, but unverified external scripts represent an unacceptable supply chain risk. By enforcing Subresource Integrity with SHA-384 digests and pinning exact release tags, you eliminate the risk of upstream script tampering.
Whether you automate hash creation in your CI/CD pipeline or use tools like the Nutilz SRI Hash Generator during development, SRI is one of the simplest and most effective security layers you can add to your web stack.
Top comments (0)