Integrity-Policy: A New Guardrail for Third-Party Scripts

Most frontend teams now understand that a third-party script is production code with a different release process, ownership model, and attack surface. Yet many sites still load analytics, payments, A/B testing, chat widgets, and CDNs with nothing more than a URL and a prayer.

Integrity-Policy is a newer browser security control that makes that implicit trust explicit. It lets a site require Subresource Integrity (SRI) metadata for scripts and stylesheets, then report or block the resource loads that do not comply. It is not a replacement for a sensible vendor review or Content Security Policy, but it is an important step toward treating the front end as a real software supply chain.

TL;DR: Integrity-Policy lets browsers enforce that selected scripts and stylesheets carry a cryptographic hash. Start with Integrity-Policy-Report-Only, inventory every external asset, fix CORS and build-pipeline issues, then enforce it for the pages where third-party code matters most.

Table of contents

1. Why third-party JavaScript is still a blind spot
2. What Integrity-Policy actually does
3. How it differs from CSP and SRI
4. A safe rollout plan
5. Implementation examples
6. The operational work people underestimate
7. Where the browser support caveat matters
8. FAQ

Why third-party JavaScript is still a blind spot

A modern page can execute code supplied by far more parties than its own repository suggests. A tag manager can add tags at runtime. A consent platform can switch vendors based on geography. A marketing campaign can add a one-off pixel. A CDN-hosted library can change independently of an application deploy.

That is convenient, but it breaks a useful security property: knowing exactly which bytes are allowed to execute in a customer’s browser.

Subresource Integrity has existed for years. A script tag can carry a hash, and the browser will refuse the file if its content does not match:

<script
  src="https://cdn.example.net/library-4.2.0.min.js"
  integrity="sha384-BASE64_ENCODED_HASH_HERE"
  crossorigin="anonymous"></script>

The practical weakness is adoption. SRI is opt-in for each individual element, so a missing integrity attribute can pass unnoticed. A later refactor can remove it. Code injected by a tag manager may never have had it. The security control exists, but the browser has no site-wide instruction to say, “scripts without integrity metadata are not acceptable here.”

That is the gap Integrity-Policy addresses.

What Integrity-Policy actually does

Integrity-Policy is an HTTP response header defined alongside the Subresource Integrity work. It tells supporting browsers to require integrity metadata for particular resource destinations, currently scripts and stylesheets.

A simple enforcement policy looks like this:

Integrity-Policy: blocked-destinations=(script style)

When the browser applies that policy, relevant resources that do not have valid integrity metadata are blocked. The policy also prevents the kinds of no-cors fetches that would make verification impossible. In practice, external resources need to be served in a way that allows the browser to fetch and validate them.

There is also a report-only version:

Integrity-Policy-Report-Only: blocked-destinations=(script style), endpoints=(integrity)
Reporting-Endpoints: integrity="https://reports.example.com/integrity"

Report-only mode is the feature’s most valuable deployment tool. Instead of breaking a checkout page because a forgotten stylesheet has no hash, it shows the failures first. A report can identify the document, blocked URL, destination, and whether the policy was report-only.

The goal is not to hash every network request. It is to establish a firm boundary around executable or presentation-critical external assets. If a resource changes unexpectedly, the browser rejects it before it can alter the page.

How it differs from CSP and SRI

These controls are complementary, not interchangeable.

SRI verifies a specific asset

The integrity attribute binds a URL reference to an expected cryptographic digest. It answers: are these the exact bytes I approved? It is excellent for versioned, immutable external assets.

CSP restricts what the page may load and execute

A Content Security Policy can restrict script origins, control inline code with nonces or hashes, limit framing, and reduce the impact of some injection bugs. It answers: where may code come from, and under what execution rules? A strong CSP is still a cornerstone of browser security.

Integrity-Policy requires the use of SRI

Integrity-Policy makes SRI a policy requirement rather than a convention developers hope to remember. It answers: must this class of resource be cryptographically verified? That makes it especially useful where the HTML is assembled by several systems or changed by non-engineering tools.

A mature setup might use all three:

• CSP limits scripts to known origins and blocks unsafe execution paths.
• SRI pins the content of external, versioned resources.
• Integrity-Policy catches missing SRI coverage and provides violation telemetry.

This layering matters because each control covers a different failure mode. A trusted origin can still serve compromised content. A correct SRI hash can still be omitted. A policy can be correct yet expose a risky third-party host unnecessarily.

A safe rollout plan

Do not begin by enforcing the header across an entire production site. The right rollout is deliberately boring.

1. Build an external asset inventory

Collect every script and stylesheet that a representative set of production pages loads. Include:

• static HTML and application templates;
• framework-managed assets;
• tag-manager injections;
• consent-management platforms;
• payment, chat, and analytics vendors;
• experiment tooling; and
• content blocks rendered from a CMS.

Your browser’s network panel is useful, but real user monitoring and Content Security Policy reports can reveal routes and conditions that manual testing misses. Do not forget authenticated pages, regional variants, and older landing pages.

2. Classify each resource

For every external asset, decide whether it is:

1. self-hosted and versioned;
2. third-party but immutable and SRI-compatible;
3. third-party and intentionally dynamic; or
4. unnecessary.

The fourth category is a gift. A policy rollout often exposes stale tags that nobody owns. Delete them rather than designing an exception around them.

For critical dependencies, self-hosting a reviewed, versioned artifact can be safer and easier to operate than depending on a mutable CDN path. That is a product and maintenance decision, not an automatic rule, but it is worth examining.

3. Add hashes at the source of truth

Generate SRI hashes in the build or deployment pipeline, not by hand in a production template. A typical command is:

openssl dgst -sha384 -binary public/vendor/widget-2.4.1.js | openssl base64 -A

Then use the output with the algorithm prefix:

<script
  src="/vendor/widget-2.4.1.js"
  integrity="sha384-PASTE_GENERATED_VALUE_HERE"
  crossorigin="anonymous"></script>

A lockfile, an immutable asset name, and an automated hash step together are more reliable than a hash pasted into a component months ago.

4. Enable report-only on a narrow route group

Start with pages you control tightly, perhaps marketing pages with no tag manager or an internal dashboard. Send reports to an endpoint that can deduplicate noise and alert the owning team. Avoid logging full URLs if they can contain user identifiers or sensitive query parameters.

Treat each report as either a defect, an intentional exception, or evidence that the page should not yet be included. “We do not know” is a valid temporary answer, but it should have an owner and expiry date.

5. Enforce gradually

Move to Integrity-Policy only after report-only violations are understood and fixed. Begin with script, then consider stylesheets. Scripts are generally the highest-value boundary because they execute code, while stylesheet enforcement can uncover more legacy and CMS-related complexity.

Keep the reporting endpoint active after enforcement. A future campaign or vendor change can silently reintroduce an unverified asset.

Implementation examples

For a Next.js application deployed behind a platform that supports response headers, add the headers at the application or edge configuration layer. The exact configuration depends on your hosting environment, but the values are standard HTTP:

// next.config.js
const nextConfig = {
  async headers() {
    return [
      {
        source: '/:path*',
        headers: [
          {
            key: 'Integrity-Policy-Report-Only',
            value: 'blocked-destinations=(script), endpoints=(integrity)',
          },
          {
            key: 'Reporting-Endpoints',
            value: 'integrity="https://reports.example.com/integrity"',
          },
        ],
      },
    ]
  },
}

module.exports = nextConfig

This only adds the policy. It does not magically hash framework-generated scripts or code injected by other tools. Before switching to enforcement, test the actual production HTML and runtime behavior.

A static site can set the same headers at the CDN or server layer:

add_header Reporting-Endpoints 'integrity="https://reports.example.com/integrity"' always;
add_header Integrity-Policy-Report-Only 'blocked-destinations=(script style), endpoints=(integrity)' always;

For a CDN resource, SRI normally also requires CORS cooperation from the asset host. The browser must be able to retrieve the resource in a mode where its contents can be checked. Validate this early with the exact domains, cache rules, and redirects used in production.

The operational work people underestimate

The header is simple. Keeping hashes meaningful is not.

Dynamic URLs are the common source of trouble. A URL such as https://cdn.vendor.com/widget/latest.js is incompatible with the point of pinning content, because latest may change without your deployment. Prefer a versioned URL, an immutable release, or a self-hosted copy that your pipeline updates deliberately.

Tag managers deserve special scrutiny. They are useful distribution systems, but they also turn browser code changes into a marketing-operations workflow. If a tag must remain dynamic, document why, restrict its privileges through CSP where possible, and avoid pretending it has the same assurance as an SRI-pinned script.

Reporting deserves care too. Violation reports are operational telemetry, not a compliance checkbox. Track a baseline, group failures by deploy and route, and assign ownership. A sudden spike after a release should be investigated with the same urgency as JavaScript errors or failed payments.

Finally, test rollbacks. A rollback to an older HTML version with newer cached assets, or vice versa, can expose hash mismatches. Versioned filenames and cache-control policies make this much easier to reason about.

Where the browser support caveat matters

Integrity-Policy is not yet a universal Baseline feature. That means you should not describe it as your only front-end supply-chain control. Browsers that do not support it will not enforce it.

That does not make it useless. Security controls can still improve protection for a portion of visitors while existing defences continue to cover everyone. The important design rule is graceful degradation: CSP, careful vendor selection, dependency review, HTTPS, and secure deployment practices must stand on their own.

Use feature support as a reason to deploy progressively, not as a reason to wait indefinitely. Report-only mode lets you build the asset inventory now. SRI improves verification in browsers that already support it. When adoption increases, the enforcement header becomes more valuable without requiring a new architectural project.

The bigger shift: browser security as deployable policy

Integrity-Policy reflects a broader change in web engineering. Front-end security is moving away from lists of best practices and toward controls that browsers can enforce and report on. The same pattern appears in CSP, Permissions Policy, COOP/COEP, and Fetch Metadata.

For teams shipping AI features, this matters even more. AI can accelerate the addition of SDKs, experiment tools, and vendor integrations. That speed increases the chance that external code enters production without a clear owner or threat model. A policy that makes unverified scripts visible is a useful counterweight.

The practical win is not a perfect, zero-vendor website. It is a system where external executable code is intentional, versioned, observable, and difficult to change silently.

FAQ

Does Integrity-Policy replace Content Security Policy?

No. CSP controls allowed sources and execution behavior. Integrity-Policy requires integrity metadata for selected scripts and stylesheets. Use them together.

Should every script use SRI?

Prioritize external, versioned, high-impact scripts. First-party build assets may also benefit, but a policy rollout should focus on resources you can inventory and keep stable. Avoid hashes for mutable latest endpoints.

Will Integrity-Policy break my tag manager?

It can reveal or block tag-manager-injected scripts that lack valid integrity metadata. Start in report-only mode, measure what the tag manager loads, and make an explicit decision for each dependency.

Can I use Integrity-Policy today?

Yes, but browser support is limited, so deploy it as an additional defence rather than the sole security mechanism. The MDN Integrity-Policy reference tracks its current behavior and compatibility.