Introduction

This error means the browser downloaded a script or stylesheet whose actual bytes do not match the hash declared in the integrity attribute. In an Ember deployment, that usually points to an asset mismatch between what was built, what was deployed, and what the browser or CDN is actually serving.

What the integrity Attribute Is Checking

Subresource Integrity, often shortened to SRI, lets the browser verify that a resource was not modified after the page was built. If the HTML says a file should have a particular SHA-based digest, the browser recomputes the digest from the downloaded content and compares the two values.

A typical script tag looks like this:

1<script
2  src="/assets/app.js"
3  integrity="sha384-EXAMPLE_HASH"
4  crossorigin="anonymous"></script>

If /assets/app.js changes but the integrity value in the HTML does not, the browser blocks the resource and shows the digest error.

Why This Happens in Ember Deployments

In an Ember app, the most common causes are deployment consistency problems rather than Ember itself being broken.

Typical root causes include:

• 'index.html and asset files coming from different build versions'
• a CDN or proxy serving stale cached assets
• post-build minification or rewriting changing the file contents
• third-party resources changing after you pinned an old SRI hash
• incomplete deployment where some files updated and others did not

The key pattern is always the same: the HTML and the actual resource bytes no longer agree.

Rebuild and Deploy Assets Atomically

The first fix is to ensure the HTML and assets come from the same build output. For Ember, that usually means rebuilding the app and deploying the entire dist result together.

ember build --environment=production

After the build, inspect the generated files in dist/assets and the references in dist/index.html. If index.html points to a hashed app bundle, that exact file must be the one your server or CDN returns in production.

A safe deployment strategy is atomic publishing:

1. build once
2. upload all assets from that build
3. upload the matching index.html
4. invalidate or version caches as needed

Do not mix assets from different build outputs.

Check Whether a CDN or Proxy Changed the File

If the build output is correct locally but production still fails, inspect the deployed asset directly. Compare the bytes being served to the built file.

curl -s https://example.com/assets/app.js -o deployed-app.js
shasum -a 384 deployed-app.js

Then compare that hash to the integrity value in the served HTML. If they differ, something in delivery changed the file or served the wrong version.

This often happens when:

• a CDN edge still has an old asset cached
• the server compresses or rewrites content incorrectly
• a post-processing step modifies JavaScript after the hash was generated

Be Careful With Third-Party Assets

If the failing resource is not your Ember bundle but a third-party script or stylesheet, the problem may be that the upstream file changed. SRI hashes are only valid for exact file contents.

For example, this kind of tag is fragile if the external file is not version-pinned:

1<link
2  rel="stylesheet"
3  href="https://cdn.example.com/library.css"
4  integrity="sha384-EXAMPLE_HASH"
5  crossorigin="anonymous">

If the CDN updates library.css, the old integrity value becomes invalid. The fix is either to pin the exact asset version and update the hash intentionally, or to stop using SRI on resources that are not actually immutable.

Debug the Served HTML, Not Just the Source Repository

A common mistake is to inspect the checked-in templates and assume that tells you what users receive. The browser error is about the final served HTML and the final served asset bytes. Always debug the deployed page itself.

Open the production page source or fetch it with curl, then inspect the referenced asset URLs and their integrity values. That narrows the problem much faster than staring at local source files.

Common Pitfalls

• Deploying index.html from one build and assets from another is the most common way to trigger SRI mismatches.
• Purging only part of a CDN cache can leave the page and its assets out of sync even when the build itself is correct.
• Letting a server or pipeline rewrite built JavaScript after Ember generated the integrity hash breaks the check immediately.
• Using SRI on mutable third-party URLs is fragile because any upstream file change invalidates the stored hash.
• Debugging the local repository instead of the actual production response wastes time when the mismatch exists only in deployed artifacts.

Summary

• The digest error means the downloaded resource bytes do not match the declared integrity hash.
• In Ember deployments, this is usually a build-version or caching mismatch, not a framework bug.
• Rebuild the app, deploy index.html and assets atomically, and verify the exact files served in production.
• Check CDN and proxy behavior if production bytes differ from the build output.
• Treat SRI hashes as valid only for immutable assets whose content will not change unexpectedly.