Integrity Policy

SRI only protects the scripts somebody remembered to hash

Subresource Integrity is only as complete as your discipline in applying it. Integrity Policy has the browser tell you about every eligible script that loaded without it — and, when you're ready, refuse to run them at all.

Start Free Trial Documentation →
What's at Stake

A hash on the tag you remembered is no help on the tag you forgot.

Subresource Integrity is an excellent defence: give a script tag an integrity attribute and the browser refuses to run the file if its contents no longer match. The weakness is not the mechanism, it is the coverage. Hashes are added by hand, tags are added by many teams, and a script injected by a tag manager or a third-party widget never passes through your review at all. The result on most sites is partial protection with no way of knowing where the gaps are.

Silent Gaps

A missing hash looks exactly like a present one

A script tag with no integrity attribute loads perfectly normally. Nothing warns you, nothing fails, and no page looks different — so an omission survives review, deployment and every subsequent release without ever being noticed.

Scripts You Didn't Write

Injected tags never had a hash to begin with

Tag managers, ad platforms and embedded widgets insert script elements at runtime. Those tags are built by somebody else's code, on somebody else's schedule, and no amount of care in your own templates puts an integrity attribute on them.

Unmeasured Coverage

You can't report on protection you can't measure

“We use SRI” is a statement about intent. Without a measurement from the browsers actually loading your pages, neither you nor an assessor can tell whether that means every eligible script or merely most of them.

What Integrity Policy Does

Measure your SRI coverage, then enforce it

One response header asks the browser to report any script that was eligible for Subresource Integrity but loaded without it. Drop the report-only suffix later and the same policy blocks them instead.

Coverage Reporting

Every eligible script that loaded unprotected

Integrity Policy reports only the genuine gaps: a script had to be eligible for SRI and to have loaded without it before an event is sent. If your coverage is already complete, nothing is reported at all — which makes an empty report a meaningful result rather than a sign that something is misconfigured.

Learn more about Integrity Policy →
Report, Then Enforce

You decide when reporting becomes blocking

Start with Integrity-Policy-Report-Only and the browser tells you about unprotected scripts while continuing to run them. When the reports show the coverage you want, remove the report-only suffix and the browser refuses to load an eligible script that arrives without integrity metadata. The same header, one word shorter.

Learn more about CSP Integrity →
Low Volume by Design

Events only when there's something to say

Because a report requires an actual gap, Integrity Policy is unusually quiet for a monitoring product. Scripts that already carry a hash generate nothing, and scripts that were never eligible for SRI generate nothing either — so the volume tracks the size of your problem, and shrinks as you fix it.

Learn more about Script Watch →
Get Started

Measure your SRI coverage. Then make it a rule.

One header. No code. Events only where a gap actually exists.

Start Free Trial Talk to our team →

30-day free trial  ·  One header  ·  No code  ·  Cancel anytime

Detection

What triggers an event, and what doesn't

Integrity Policy is deliberately narrow. Knowing exactly when it does and does not fire is what makes a quiet account trustworthy rather than suspicious.

Situation What happens
Eligible script loaded without SRI An event is reported — this is the gap the policy exists to find
Script already carries an integrity attribute Nothing is reported; the protection you wanted is in place
Script was never eligible for SRI Nothing is reported; the policy does not manufacture findings
Header sent as Report-Only The script still loads and runs; you are only being told
Header sent without Report-Only The browser blocks the script and reports that it did
No gaps anywhere on the site No events at all — a clean result, not a broken setup

Because events are only generated by real gaps, the reporting volume tracks the size of the problem and falls away as coverage improves.

Architecture

One response header. No code. No crawlers.

Integrity Policy is part of the Subresource Integrity specification, implemented in the browser. The browser evaluates your policy against the scripts it loads and reports over the Reporting API. Nothing of ours runs on your pages, and the coverage figure describes what real visitors received.

Start in report-only and nothing changes for your visitors. One header is the entire deployment.

Minimal setup — report-only, nothing blocked
Integrity-Policy-Report-Only: blocked-destinations=(script),
  endpoints=(default)

Reports travel over the Reporting API, so you will also need a Report-To group pointing at your Report URI endpoint — the exact header is on your Setup page. To enforce later, send the same header as Integrity-Policy.

No code added to your pages

No crawler fetching your scripts

Report-only mode blocks nothing while you measure

Your site's performance is unaffected

Covers runtime-injected tags your templates never touch — tag managers, ad platforms, embedded widgets

PCI DSS 6.4.3

Integrity Policy and assured script integrity

Requirement 6.4.3 asks that the integrity of each payment page script is assured, and the standard's guidance names Subresource Integrity as the first mechanism for doing it. Claiming SRI is straightforward; demonstrating that it covers every eligible script is the harder part. Integrity Policy produces that demonstration from the browsers loading your pages, and can enforce the requirement rather than merely describing it.

Identification of the files themselves is CSP Integrity's job, inventory is Script Watch's, and the wider evidence layer is set out on the PCI DSS Compliance page.

PCI DSS Compliance →
Scope

One layer in the stack. Here's how it fits.

Integrity Policy is about whether protection is present, not about what the protected file contains. It measures and enforces SRI coverage — identifying the scripts themselves is a different job, handled alongside it.

Integrity Policy does Pairs with
Reports eligible scripts loaded without SRI CSP Integrity for identification — naming the library and version behind each file
Blocks unprotected scripts once enforced CSP for load control — deciding which sources may be used at all
Measures coverage from real sessions Script Watch for inventory and change detection — knowing when the set of scripts moves
Turns intent into a demonstrable control Threat Intelligence for IoC matching — identifying known malicious sources

Together, these form the client-side security visibility layer that sits between your CSP policy and your incident response process.