Integrity-Policy gains support in Chrome and Firefox
The web security story around Subresource Integrity (SRI) is entering a new phase. After years of relying primarily on per-tag integrity attributes, browsers are now moving toward policy-based enforcement that lets sites declare, at the response-er level, that scripts (and eventually styles) must carry valid integrity metadata. The emerging centerpiece of this shift is the Integrity-Policy er, along with its non-blocking sibling, Integrity-Policy-Report-Only.
With Firefox 145 adding initial support and Chrome aligning through the W3C Subresource Integrity specification, Integrity-Policy is gaining real momentum in major browsers. That makes now an ideal time for developers, security teams, and platform engineers to understand what the feature does, how it differs from classic SRI, and how to roll it out safely across modern web applications.
From Classic Subresource Integrity to Policy-Based Enforcement
Subresource Integrity started as a per-element mechanism: you attach an integrity attribute to a <script> or <link rel="stylesheet"> tag, and the browser verifies that the fetched resource’s hash matches the expected value. If the file has been tampered with, the load fails, protecting users from manipulated CDNs or compromised third-party assets. This model works well but requires discipline: every critical subresource must be annotated manually.
In practice, many applications never reach full coverage. Scripts are added quickly, tags are generated by build tools, and legacy pages accumulate technical debt. As a result, SRI is often applied selectively, only to a few external libraries or CDN resources, leaving other subresources exposed. Worse, it is easy to forget to add integrity attributes when new bundles, micro-frontends, or third-party widgets are introduced.
Integrity-Policy responds to this reality by turning integrity from an opt-in attribute into an enforceable site-wide rule. Instead of saying “this single script must have integrity,” a site can say “no scripts (and later styles) may load without integrity metadata.” This moves SRI into the same policy-driven space as Content Security Policy (CSP), making it easier to standardize expectations, detect gaps, and gradually push an entire codebase toward stronger guarantees.
What the Integrity-Policy Headers Actually Do
The W3C Subresource Integrity Recommendation includes a dedicated section on Integrity-Policy (section 3.8), defining two related HTTP response ers: Integrity-Policy and Integrity-Policy-Report-Only. Both ers express a structured policy that user agents interpret when loading subresources such as scripts and styles. The MDN documentation now reflects this model, describing Integrity-Policy as the enforcement layer on top of classic SRI attributes.
At a high level, Integrity-Policy instructs the browser to block certain resource loads that lack SRI metadata or are requested with no-cors. When enforcement is active and a load does not satisfy the policy, the request is treated as a failure, and the resource is not executed or applied. By contrast, Integrity-Policy-Report-Only simulates this behavior without blocking, generating reports about would-be violations so that site operators can see what would break if they turned on enforcement.
This split between enforcement and report-only is intentional and mirrors CSP’s evolution. MDN’s Subresource Integrity overview explicitly recommends starting with Integrity-Policy-Report-Only as a discovery mechanism, then moving to Integrity-Policy once violations have been addressed. In other words, Integrity-Policy is not an isolated feature but part of a broader ecosystem of declarative security controls that support incremental hardening.
The Policy Model: Destinations, Sources, and Reporting Endpoints
The design of Integrity-Policy uses a policy-as-data model, expressed as a small structured dictionary in the er value. According to the spec and MDN, this dictionary is built from three core pieces: blocked-destinations, sources, and endpoints. Together, they tell the browser which resources to scrutinize, where the integrity metadata comes from, and where to report violations.
blocked-destinations is the most immediately relevant key. It is a list of fetch destinations, currently focused on script and, in the future, style, for which integrity metadata is mandatory. If script is present, the browser must consider any script load without valid integrity information to be a violation. MDN emphasizes that user agents also treat no-cors requests as failures under the policy, to prevent attackers from leveraging opaque responses that bypass integrity checks.
The sources key indicates where integrity metadata is expected to originate. At present, the spec and MDN mention inline, corresponding to the familiar integrity attribute on individual tags. The endpoints key connects the policy to the Reporting API by naming reporting endpoints that have been declared via the Reporting-Endpoints er. When wired up, the browser can POST JSON payloads with type integrity-violation and an IntegrityViolationReportBody, including fields such as documentURL, blockedURL, destination, and reportOnly, to centralized telemetry services.
Firefox 145: Concrete Support and Current Limitations
Mozilla’s Firefox 145, currently in beta and scheduled for release on 11 November 2025, marks a concrete milestone for Integrity-Policy adoption. According to the Firefox 145 release notes and MDN’s Firefox release documentation, this version adds support for both Integrity-Policy and Integrity-Policy-Report-Only response ers. Initially, enforcement is scoped to script resources, aligning with the blocked-destinations design but not yet covering stylesheets.
Releasebot’s summary of Firefox 145 explicitly highlights Integrity-Policy as a new web-platform feature: “Firefox now supports the new Integrity-Policy er for enforcing sub-resource integrity for scripts. Further implementation of this er is underway.” This public messaging indicates that Mozilla views Integrity-Policy as a foundational capability to be iterated upon, not a one-off experiment. Developers can therefore treat the feature as part of the browser’s future-facing security model.
One important caveat in this initial rollout is that the endpoints key is not yet functional in Firefox 145. While the browser enforces policies for scripts and recognizes both enforcement and report-only modes, violation reports are currently logged only to the developer console. Integration with the Reporting API via named endpoints, allowing for server-side collection and analysis, is planned but not yet shipped. For now, teams can test Integrity-Policy’s behavior and begin cleaning up violations but will need to rely on local logs rather than automated telemetry pipelines.
Chrome and Chromium: Spec-Level Alignment and Emerging Support
On the Chrome and Chromium side, Integrity-Policy’s story is more driven by standards alignment than by a single, line-grabbing release note. The W3C Subresource Integrity Recommendation, which defines the Integrity-Policy section and associated ers, is a core reference for browser vendors, including the Chromium project. MDN’s cross-browser framing of the feature also strongly suggests ongoing work and adoption across the Chromium ecosystem.
While public Chrome version notes have been less explicit than Firefox’s about Integrity-Policy as of late 2025, the presence of the mechanism in the SRI spec and MDN’s documentation typically indicates either existing implementation or active development in Chromium-based browsers. In practice, that means web developers can plan around Integrity-Policy as a multi-browser concept rather than something confined to a single vendor. Over time, we can expect Chrome to converge on the same vocabulary, blocked-destinations, sources, endpoints, and the integrity policy processing algorithm, described in the spec.
This spec-level convergence is important for ecosystem stability. Security ers only reach their potential when they behave consistently across engines. The Subresource Integrity spec describes not just the er syntax but also the underlying “integrity policy” structure and processing algorithm that user agents must follow. As Chrome and Firefox both move toward that shared behavior, developers will be able to rely on Integrity-Policy as a predictable, interoperable control in production environments.
Security Benefits: Hardening Against Manipulated Subresources
The core security motivation behind Integrity-Policy is to reduce the attack surface created by manipulated subresources. Traditional SRI helps ensure that a specific script or stylesheet has not been tampered with, but it is optional per tag. If new resources are added without integrity attributes, or if an attacker can inject a new script tag with no integrity, there is no built-in guarantee that those loads will be blocked.
Integrity-Policy addresses this gap by flipping the default. When enforced, it allows a site to assert, “No scripts (and eventually styles) may load unless they have valid integrity metadata,” and it empowers the browser to treat missing integrity as a policy violation. That makes it significantly harder for an attacker who has gained partial control over a page or a template to quietly introduce new, unchecked subresources, those requests will simply fail under the policy.
Additionally, by treating no-cors requests as failures in the context of Integrity-Policy, user agents can close a subtle loophole. Opaque responses, where the browser does not expose the full response details to JavaScript, can otherwise be used to fetch unverified content. By folding these into the integrity enforcement model, Integrity-Policy helps ensure that attackers cannot sidestep SRI protections via alternative fetch modes or cleverly crafted cross-origin requests.
Deploying Integrity-Policy Safely: Start with Report-Only
Although Integrity-Policy promises stronger guarantees, it is also capable of breaking pages if deployed too aggressively. Many existing sites lack comprehensive integrity coverage, and some build pipelines still do not automatically generate integrity attributes for all bundles. To navigate this reality, MDN and the SRI spec recommend an incremental rollout pattern centered on Integrity-Policy-Report-Only.
The recommended first step is to enable Integrity-Policy-Report-Only with appropriate blocked-destinations (starting with script) and, when available, configured endpoints tied to the Reporting API. In this mode, the browser does not block any loads but records every instance where a resource would have been blocked, because it lacks integrity metadata or is fetched with no-cors. These reports, when collected centrally, provide an inventory of missing integrity attributes and problematic request patterns.
Once developers and security teams have analyzed the telemetry, updated build systems, and added the necessary integrity attributes across their codebase, they can move to full enforcement by switching to Integrity-Policy. At that point, non-compliant subresource loads will be blocked outright. This staged journey from report-only to enforcement is a proven pattern from CSP and helps teams avoid sudden outages while still moving steadily toward a more secure default posture.
Integrity-Policy and its report-only variant represent a natural next step in the evolution of web integrity controls. By elevating integrity requirements into a first-class policy, they let sites express broad, enforceable expectations about how scripts and styles are loaded, while still building on the familiar SRI primitives developers already know. With Firefox 145 shipping initial support and Chromium aligning with the W3C Subresource Integrity specification, this model is poised to become a mainstream tool in the browser security toolkit.
As implementation matures, expanding coverage from scripts to styles, wiring endpoints through the Reporting API, and harmonizing behavior across Chrome and Firefox, developers will gain a more robust, interoperable way to defend against subresource tampering. The practical path forward is clear: start by experimenting with Integrity-Policy-Report-Only, clean up violations and strengthen build pipelines, then move toward full enforcement. In doing so, teams can help push the web toward a safer default, where silently loading unchecked code becomes far harder for attackers to achieve.