What is Subresource Integrity (SRI)?

Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources fetched from external sources (like CDNs) have not been tampered with. It works by comparing a cryptographic hash of the fetched resource against a hash you provide in your HTML.

If an attacker compromises a CDN or performs a man-in-the-middle attack, SRI prevents your users from executing malicious code because the hash won't match. This is a critical defense-in-depth measure for any website using third-party resources.

How SRI Works

1. Generate Hash: Calculate the cryptographic hash (SHA-256, SHA-384, or SHA-512) of the resource file
2. Add Integrity Attribute: Include the hash in your script or link tag's integrity attribute
3. Add Crossorigin: For cross-origin resources, add crossorigin="anonymous"
4. Browser Verification: When loading, the browser fetches the resource and calculates its hash
5. Match Check: If hashes match, the resource executes. If not, it's blocked.

SRI Syntax Examples

JavaScript File

<script src="https://cdn.example.com/library.min.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

CSS Stylesheet

<link rel="stylesheet"
      href="https://cdn.example.com/styles.min.css"
      integrity="sha384-MCw98/SFnGE8fJT3GXwEOngsV7Zt27NXFoaoApmYm81iuXoPkFOJwJ8ERdknLPMO"
      crossorigin="anonymous">

Why Use SHA-384?

While all three algorithms (SHA-256, SHA-384, SHA-512) are secure, SHA-384 is recommended for several reasons:

• Security margin: 192 bits of security vs. 128 bits for SHA-256
• Performance: SHA-384 is actually faster than SHA-256 on 64-bit systems (same as SHA-512)
• Future-proofing: Provides resistance against potential future attacks
• Standard practice: Major CDNs like cdnjs and Bootstrap use SHA-384

SRI and CORS

For SRI to work with cross-origin resources, the server must allow CORS (Cross-Origin Resource Sharing). You must also include the crossorigin attribute in your HTML:

Real-World SRI Attack Prevention

SRI has prevented several potential supply chain attacks:

• British Airways (2018): Attackers injected malicious code into a third-party script. SRI could have prevented this.
• event-stream NPM package (2018): A popular package was compromised to steal cryptocurrency. SRI for CDN-hosted versions would block the malicious update.
• Codecov breach (2021): Bash Uploader script was modified. Organizations using SRI verification detected the change.

When to Use Multiple Hashes

You can specify multiple hashes for a single resource, useful during version transitions:

<script src="https://cdn.example.com/lib.js"
        integrity="sha384-oldHash sha384-newHash"
        crossorigin="anonymous"></script>

The browser accepts the resource if any of the provided hashes match.

SRI Limitations

• Dynamic resources: SRI won't work for resources that change frequently
• Same-origin resources: While optional, SRI is still recommended
• Inline scripts: SRI only works for external resources, not inline code
• Browser support: Older browsers (IE) don't support SRI (they'll ignore the attribute)

Implementing SRI in Your Build Process

For production environments, integrate SRI hash generation into your build pipeline:

Webpack (webpack-subresource-integrity)

const SriPlugin = require('webpack-subresource-integrity');

module.exports = {
  output: { crossOriginLoading: 'anonymous' },
  plugins: [new SriPlugin({ hashFuncNames: ['sha384'] })]
};

Command Line (OpenSSL)

cat file.js | openssl dgst -sha384 -binary | openssl base64 -A

Node.js

const crypto = require('crypto');
const hash = crypto.createHash('sha384').update(fileContent).digest('base64');
console.log(`sha384-${hash}`);