The CDN delivers JavaScript — is it still the file you approved?

HTTPS protects the connection. It does not prove that a file on a legitimate CDN or third-party host has remained unchanged since your last review. If a vendor is compromised or a file is replaced at the same URL, the browser may still download perfectly encrypted JavaScript — just not the JavaScript you expected.

Subresource Integrity (SRI) adds a cryptographic hash to that trust decision. Before execution, the browser checks whether the delivered bytes match the expected hash. If they do not, the resource is not executed.

The W3C Subresource Integrity Level 2 Working Draft published on March 20, 2026 extends this model and also defines Integrity-Policy and Integrity-Policy-Report-Only.

Myth: “HTTPS is enough for a CDN script”

HTTPS answers: “Am I talking securely to the expected host?”

SRI answers: “Is this exactly the file I approved?”

That matters for CDN libraries, payment and support widgets, analytics, consent tools, A/B testing, and other external frontend dependencies. OWASP notes that third-party JavaScript can change outside your release process while executing with powerful capabilities in the context of your site.

What SRI actually checks

For supported script and link resources, the integrity attribute can contain hashes using SHA-256, SHA-384, or SHA-512. For example:

<script src="https://cdn.example.com/widget-4.2.1.js" integrity="sha384-…" crossorigin="anonymous"></script>

The browser hashes the response. If it does not match the expected metadata, the resource fails as a network error.

That is both the security benefit and the operational trade-off. If a provider silently changes https://vendor.example/latest.js, SRI prevents execution — but a feature on your site may also stop working.

That is why versioned, preferably immutable URLs and SRI belong together. Updating should be deliberate: review the new version, test it, update the hash, and deploy the URL and hash together.

Multiple hashes need governance

SRI allows multiple hash values. W3C and MDN specify that the browser uses the strongest supported hash algorithm present; multiple hashes at that strength can explicitly allow multiple known representations.

That can help during a controlled rollout. It should not become a permanent list of historical approvals. Review:

• who generates and approves hashes,
• why multiple values exist,
• which versions are still valid,
• when old hashes are removed.

Cross-origin SRI requires CORS

For external resources, SRI relies on CORS. The provider must return appropriate CORS headers, and consuming markup commonly uses crossorigin="anonymous".

A common failure is to add SRI directly in production and only then discover that the vendor does not serve the asset with compatible CORS headers. Test the hash, CORS behavior, and failure path together.

The tag-manager trap

A hash on a loader protects that loader. It does not automatically attest every script the loader fetches later.

Tag managers, consent platforms, and widget bootstrappers can load additional resources from different hosts. The useful question is therefore not just:

“Does this script tag have an integrity attribute?”

It is:

“What executable dependency chain starts from this entry point?”

Inventory the real browser network activity, not only the static HTML.

New in SRI Level 2: Integrity Policy

The current W3C draft describes Integrity-Policy and Integrity-Policy-Report-Only. A document can use them to require integrity metadata for selected resource destinations, currently notably scripts and stylesheets, and report violations.

A sensible rollout starts in report-only mode:

1. enable Integrity-Policy-Report-Only,
2. collect violations,
3. identify forgotten and dynamically loaded resources,
4. close SRI and CORS gaps,
5. only then consider blocking enforcement.

MDN currently marks Integrity-Policy as Limited availability. It should not be your only protection layer today. Report-only is particularly useful as an observability tool while browser support and your own compatibility requirements evolve.

A practical SRI review

On a production page, check:

• Which third-party scripts and styles actually load?
• Are their URLs versioned, or do they mutate behind names such as latest, loader, or embed?
• Where is SRI missing for static, versionable files?
• Do CORS and crossorigin work correctly?
• What happens with a deliberately incorrect hash?
• Which scripts dynamically load more scripts?
• Who owns vendor updates, new hashes, and regression testing?

What Website-Pflichtencheck would inspect

Website-Pflichtencheck can review the real external loading chain: third-party hosts, mutable versus versioned URLs, SRI metadata, hash choices, CORS behavior, dynamic dependency chains, tag-manager relationships, failure behavior, and the practical update process.

Where appropriate, it can also evaluate whether Integrity-Policy-Report-Only is useful as an observability layer.

The goal is not to ban third-party scripts. The goal is to turn “we trust this URL” into a verifiable operating statement:

“We know which file is approved, we detect unexpected changes, and we have a controlled path for updates.”