Correct SRI Hash Still Blocked? Causes & Fixes

If you are seeing a script blocked by Content Security Policy (CSP) even though the integrity attribute (the SRI hash) on your <script> tag is correct, the most likely cause is that the resource is being loaded from a domain that is not listed in your CSP’s script-src directive. SRI validates the file’s contents, but CSP controls where the browser is allowed to fetch it from; a correct hash does not bypass a missing domain allowlist.

This article explains the difference between SRI and CSP, why a correct hash can still trigger a block, and how to diagnose and fix the issue.

What SRI Actually Does

Subresource Integrity (SRI) is a browser security feature that lets you specify a cryptographic hash of a script or style file. When the browser fetches the file, it computes its hash and compares it to the integrity value. If they match, the file is executed; if they don’t, the browser refuses to run it. SRI protects against a compromised CDN or a man-in-the-middle attack that alters the file contents.

However, SRI only checks what the file is, not where it comes from. The browser’s network stack still enforces the page’s Content Security Policy before the file is even downloaded. If the URL is not allowed by script-src, the request is blocked before SRI has a chance to run.

How CSP Differs from SRI

Content Security Policy is a separate security layer that controls which origins the browser may connect to, which scripts may execute, and other resource-loading rules. A typical CSP header might look like:

Content-Security-Policy: script-src 'self' https://cdn.example.com

This allows scripts from your own domain and from https://cdn.example.com. If your script tag points to https://other-cdn.com, the browser blocks it immediately—even if the integrity hash is perfectly valid. The error message in the console will often say something like “Refused to load the script … because it violates the following Content Security Policy directive: script-src ‘self'”.

To allow a script with a correct SRI hash, you must add the script’s origin to your CSP. For example, if you use a CDN, your CSP should include that CDN’s domain.

Common Reasons a Correct Hash Gets Blocked

Here are the most frequent causes, in order of likelihood:

Missing origin in CSP: The script’s domain is not in script-src. This is the most common cause.
Scheme mismatch: Your CSP allows https: but the script is loaded over http: (or vice versa). Browsers treat these as different origins.
Port mismatch: If your CSP specifies a port (e.g., https://cdn.example.com:8443) but the script uses the default port, it won’t match.
Path-based CSP: Some CSPs use path restrictions (though this is discouraged). If the script’s path doesn’t match, it’s blocked.
Nonce or hash conflict: If you use a CSP nonce or an inline script hash, and your script tag has a nonce that doesn’t match, it will be blocked.
Browser cache: An older cached version of the script (without the correct hash) may be served, causing a mismatch. Hard-refresh or clear cache.

How to Diagnose the Block

To find out exactly why a script is blocked, open your browser’s developer console (F12) and look at the error message. It will usually tell you:

Which resource was blocked (the URL).
Which CSP directive caused the block (e.g., script-src).
The exact reason (e.g., “the source list is empty” or “the source … is not allowed”).

If the message says “violates the following Content Security Policy directive,” then the issue is CSP, not SRI. If it says “integrity check failed,” then the hash is wrong or the file changed.

Fixing the Issue

Once you know the cause, the fix is straightforward:

Add the script’s origin to your CSP. In your server configuration, update the script-src directive to include the domain, e.g., script-src 'self' https://cdn.example.com.
If using a nonce, ensure it matches. If your CSP uses a nonce, the script tag must have the same nonce value. If you’re using a static HTML page, you can’t use a nonce effectively—use a hash instead.
If using an inline script hash, ensure it matches exactly. The hash must be of the exact script content, including whitespace.
Clear the browser cache. Sometimes an old cached version of the script (or the HTML page) causes confusion. Do a hard refresh (Ctrl+F5) or clear cache.
Test with a minimal CSP. Temporarily set script-src * to see if the script loads. If it does, the issue is definitely the CSP. Then narrow down the allowed origins.

If you are using a CDN that changes its file (e.g., a versioned URL that updates), you must update the SRI hash accordingly. Many CDNs provide the correct hash for each version.

Comparing SRI and CSP: A Quick Reference

Feature	SRI	CSP
Checks file integrity	Yes	No
Checks source origin	No	Yes
Blocks modified files	Yes	No
Blocks unauthorized domains	No	Yes

They are complementary: SRI ensures the file hasn’t been tampered with, while CSP ensures it comes from a trusted location.

Frequently Asked Questions

Why does my script load in one browser but not another?

Different browsers may enforce CSP differently, or one browser may have a cached version that passes SRI while another fetches a new version that fails. Also, browser extensions can modify the page’s CSP or block scripts. Check the console in the failing browser for specific errors.

Can I use SRI without a CSP?

Yes, SRI works independently of CSP. If you don’t have a CSP header, the script will load as long as the hash matches. However, without CSP, you lose protection against malicious domains, so it’s best to use both.

Does SRI work for inline scripts?

Yes, you can use SRI for inline scripts by specifying a hash in the integrity attribute, but you must also include the hash in your CSP’s script-src (e.g., 'sha256-...'). The hash must match the exact content of the inline script.

What if the CDN serves a different file to different users (e.g., A/B testing)?

If the CDN changes the file content based on user agent or other factors, the SRI hash will fail for some users. In that case, you cannot use SRI reliably. You would need to serve the file from your own domain or use a CDN that serves identical content to everyone.

How do I generate the correct SRI hash?

You can use an online SRI generator or run a command like openssl dgst -sha384 -binary <file> | openssl base64 -A in a terminal. The output is the base64-encoded hash. Then prepend sha384- to it for the integrity attribute.

Why does the console say “Required SRI integrity attribute is missing” even though I have it?

This error usually means the integrity attribute is not on the <script> tag itself, but on a parent element, or the attribute name is misspelled. Double-check that the tag looks like <script src="..." integrity="sha384-..." crossorigin="anonymous">. Also note that for cross-origin scripts, the crossorigin attribute is required for SRI to work.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →