Subresource Integrity Explained: Generate SRI Hashes for CDN Scripts and Stylesheets

Overview

SRI uses the integrity attribute on an external <script> or stylesheet <link> element. The attribute contains a cryptographic hash of the exact resource bytes. When the browser downloads the file, it compares the downloaded content with the declared hash. If the values do not match, the resource is not used.

A typical CDN script looks like this:

<script src="https://cdn.example.com/library@1.2.3/library.min.js" integrity="sha384-BASE64_HASH_HERE" crossorigin="anonymous"></script>

For a stylesheet, the pattern is similar:

<link rel="stylesheet" href="https://cdn.example.com/library@1.2.3/library.min.css" integrity="sha384-BASE64_HASH_HERE" crossorigin="anonymous">

The hash is not a password, signature, or replacement for HTTPS. It is an integrity check tied to one exact response. If the CDN URL points to a different version, the file is rebuilt, or the response is modified, the existing hash may no longer match. Treat the URL and hash as a pair that must be reviewed together.

For related page-hardening work, see the Content Security Policy guide. SRI is one control in a broader web security and web developer tools workflow.

Checklist by scenario

Adding SRI to a CDN script

1. Choose a versioned CDN URL rather than an unpinned URL such as /latest/.
2. Download the exact URL that production will request.
3. Generate a supported digest, commonly SHA-384 or another algorithm supported by your target browsers and deployment environment.
4. Base64-encode the digest in the format required by the integrity attribute, such as sha384-....
5. Copy the hash without changing its capitalization, punctuation, or padding.
6. Add integrity and, for a cross-origin resource, configure crossorigin="anonymous" as appropriate.
7. Load the page in a clean browser session and check the developer console and Network panel.

Adding SRI to a stylesheet

1. Confirm that the downloaded CSS is the file referenced by the final href, including any version, path, and query string.
2. Generate the hash from the response body, not from a formatted copy opened in an editor.
3. Place the hash on the same <link> element as the final production URL.
4. Test both the initial page load and any route or component that depends on the stylesheet.

Generating a hash from the command line

Save the CDN response to a file, then hash that file. For example, with command-line tools available on many development systems:

curl -L 'https://cdn.example.com/library@1.2.3/library.min.js' -o library.min.js
openssl dgst -sha384 -binary library.min.js | openssl base64 -A

Prefix the resulting Base64 value with sha384- and place the complete value in the HTML attribute. The -L option follows redirects while downloading; still verify that the resulting file and final URL match what your deployment is intended to use.

A browser-based SRI hash generator can be useful for a quick inspection, but do not paste private or proprietary code into an online developer tool unless your organization permits it. For repeatable releases, a local command or build step is usually easier to audit.

Managing SRI in a build pipeline

Manual generation is reasonable for a small static page with infrequent dependency changes. A build pipeline is safer when dependencies are updated regularly or when several pages share the same asset. The pipeline can download or read the release artifact, calculate the digest, inject the hash into generated HTML, and fail if the URL and artifact do not correspond.

Keep the generated hash visible in the build output or artifact manifest. Review changes to both the dependency version and the resulting integrity value. Do not silently regenerate hashes from whatever a mutable CDN URL returns at build time without recording the version and source decision.

What to double-check

• Exact bytes: SRI checks the response content. A locally prettified, minified, decompressed, or line-ending-adjusted copy can produce a different hash.
• Exact URL: Confirm the protocol, hostname, path, version, filename, and relevant query parameters. A different response means a different hash may be required.
• HTML placement: Put the attribute on the external script or stylesheet element that loads the resource. It does not belong on an unrelated wrapper element.
• Cross-origin behavior: Cross-origin resources must be delivered in a way that allows the browser to inspect the response for integrity checking. Check the CDN response and browser console if the resource is blocked.
• Algorithm support: Use a digest algorithm supported by the browsers and environments you need to serve. SHA-384 is a common practical choice, but compatibility should be part of your own testing.
• Cache layers: A stale service worker, proxy, or edge cache can make debugging confusing. Compare the requested URL, response headers, and response body in the Network panel.
• Fallback planning: If an SRI check fails, the resource may not load. Decide whether the page should fail clearly, use a separately verified local asset, or follow another documented recovery path.

If the failure appears alongside other cross-origin messages, use the CORS troubleshooting checklist to separate response-access problems from an incorrect hash.

Common mistakes

Hashing the URL instead of the response

The digest is calculated from the downloaded file contents, not from the text of the URL. Hashing the address string will create a value the browser cannot use.

Using a mutable CDN alias

An alias such as latest can point to new content without an HTML change. The old SRI hash will then block the new response, or a rushed update may encourage someone to remove SRI. Pin a known version and update the URL and hash deliberately.

Copying an incomplete hash

Missing the algorithm prefix, truncating the Base64 value, or introducing a line break can invalidate the attribute. Copy the complete single-line value and inspect the rendered HTML, not only the template source.

Testing only one page

Templates, cached HTML, route-specific bundles, and alternate deployment environments can use different resource URLs. Search the built output for every occurrence of the dependency and test the production-shaped artifact.

Removing SRI to make an error disappear

A mismatch is a signal to investigate the URL, artifact, CDN response, cache, and deployment process. Removing the check hides the problem rather than identifying its cause.

When to revisit

Return to this checklist whenever a dependency is upgraded, a CDN provider or URL changes, a file is re-minified, or a production page reports that a resource was blocked by its integrity policy. Also revisit SRI during planned seasonal or periodic maintenance cycles, especially before publishing a new static-site build or changing cache rules.

A practical maintenance routine is:

1. List every externally loaded script and stylesheet.
2. Confirm each URL is intentionally versioned and still required.
3. Regenerate hashes only from the release artifacts that will be served.
4. Review the generated HTML and test a clean production-like page load.
5. Record the dependency version, URL, algorithm, and hash in the change or build artifact.
6. Investigate browser console failures before approving the release.

For a repeatable HTML validation workflow, consult How to Validate and Debug an HTML File. If you are creating a new page, the HTML5 starter template generator can provide a clean starting structure. The goal is not to add a hash once and forget it; it is to keep the approved resource, generated artifact, and deployed HTML synchronized as your developer tools and workflow change.