Subresource Integrity Hash Generator

Loading a CDN-hosted script without subresource integrity is trusting that CDN's entire ops team forever. If the file changes — through compromise or a maintainer's mistake — your site executes whatever the new version contains, including any malicious code. SRI hashes prevent this by making the browser refuse to execute the script unless its hash matches.

Paste a URL or upload a file and the generator returns a sha384 (and optionally sha512) integrity attribute ready to drop into your script or link tag. Output is the standard format browsers expect: integrity="sha384-Base64Hash" plus the matching crossorigin="anonymous" that's required for the integrity check to fire.

Worth doing for any third-party script. The cost is one regeneration when the script version changes; the benefit is an entire class of supply-chain attack closing. It's free defense in depth that takes thirty seconds per script.

What Subresource Integrity actually does is straightforward: when the browser fetches a script or stylesheet that has an integrity attribute, it computes the hash of the response body and compares it to the declared hash. Match: the resource is allowed to execute. Mismatch: the browser refuses. The hash is the standardized output of a cryptographic hash function (sha256, sha384, or sha512) on the file's exact bytes, encoded as Base64. The hash uniquely identifies the file content; any modification — malicious or innocent — changes the hash and triggers the integrity failure.

Worked example for a CDN-hosted React: <script src="https://unpkg.com/react@18/umd/react.production.min.js" integrity="sha384-2tmZ+EObzL0xOYGBi9uqBCjwkA56b5Tfg4PD7qK7qDKyAuyA6LnP9dEnH0Vw1mb6" crossorigin="anonymous"></script>. The browser fetches the file, computes its SHA-384, Base64-encodes it, compares to the declared value. If the CDN is compromised and serves modified React with malicious code, the hash differs, the browser blocks execution, and your site breaks visibly rather than running attacker code silently. The visible breakage is the security feature.

The practical limits: you have to update the hash whenever the file changes, which means versioned URLs (react@18.2.0/...) or accepting that your build pipeline regenerates and updates hashes whenever dependencies change. Pinning to a major version (react@18) without version specificity means the file can change under you and your hash will fail; pin to a specific version. The crossorigin="anonymous" attribute is mandatory for cross-origin SRI — without it, the browser doesn't expose the response body for hash checking and the integrity check silently fails (script loads anyway, defeating the point).

For first-party assets served from your own domain, SRI's value diminishes because you control the source. Some teams still use it as defense-in-depth against hosting compromise, on the theory that an attacker who breaches your CDN would also have to alter the HTML referencing the assets. That's a real but secondary defense; the first-order benefit of SRI is for third-party CDN-hosted code, where you don't trust the operator with arbitrary code execution on your visitors. Apply it to every third-party script in production. The cost is one regeneration per version bump; the benefit is closing an entire supply-chain attack class.