SaaSFort Subresource Integrity has been available for a decade. You add a hash to a script tag, the browser verifies the file matches before executing it, and a compromised CDN can no longer serve you modified code.
It works. It also has a structural flaw that has nothing to do with cryptography: it is opt-in, one tag at a time.
How SRI coverage decays
A team audits their third-party scripts, adds integrity attributes to all of them, and passes the check.
Six months later there is a new analytics vendor, a support widget added by the marketing team, and an A/B testing snippet pasted from a dashboard. None of them have an integrity attribute, because nothing required one.
Your SRI coverage is now partial, and partial SRI protects nothing: an attacker compromising the CDN only needs one unprotected script.
This is the normal outcome, not a failure of discipline. Any control that depends on every future developer remembering it will degrade.
What Integrity-Policy does
Integrity-Policy is a response header from SRI Level 2 that moves the requirement from the tag to the page. When set, the browser blocks any request for the specified destination that arrives without integrity metadata.
Integrity-Policy: blocked-destinations=(script), endpoints=(integrity-endpoint)
Reporting-Endpoints: integrity-endpoint="https://yourdomain.com/_reports/integrity"
The new script someone adds next quarter without an integrity attribute does not execute. It does not partially work or fail silently in a way nobody notices: it is blocked, and a report is sent.
It also blocks no-cors mode requests outright, closing the path where a script is fetched in a mode that makes integrity verification impossible.
The gotcha that will bite you
There is no way to distinguish first-party from third-party resources in Integrity-Policy.
If you enable it, every script needs an integrity attribute, including your own bundles. For a site with hashed build output this is a build step. For a site that serves /app.js and overwrites it on each deploy, it is a real change to your pipeline, because the hash in the HTML must be regenerated with the bundle.
This is by design. The header comes out of an effort to bring app-store-style code signing to the web, where the guarantee is that nothing on the page was tampered with, not merely that the third-party parts were not.
Plan for it. The build tooling for most frameworks emits SRI hashes with a flag or a small plugin, but it is a change to make deliberately rather than discover in production.
Browser support in 2026
| Browser | Status |
|---|---|
| Chromium | Shipped from Chrome 130 |
| Firefox | Partial from Firefox 145, script destination only |
| Safari | Not yet |
Partial coverage is still worth deploying. The header is ignored where unsupported, so there is no compatibility risk, and the majority of traffic gets the enforcement.
Deploy it in report-only first
Integrity-Policy-Report-Only: blocked-destinations=(script), endpoints=(integrity-endpoint)
In report-only mode the browser allows the violating request and reports it. This is the safe first step and it produces the thing you actually want early: a complete list of every script currently served without integrity metadata, gathered from real page loads rather than from a crawl.
Work that list down to zero, then switch the header to enforcing.
You can also observe violations in JavaScript with a ReportingObserver registered for integrity-violation, which is useful during migration.
Why this belongs in a vendor security answer
Supply-chain compromise through a third-party script is one of the few attacks that bypasses essentially every control a SaaS vendor is usually asked about. The code is served from an allowed origin, over TLS, to an authenticated user, inside a page with a valid CSP. CSP explicitly does not defend against this: it verifies where a script came from, not what the script contains.
Enterprise security teams have started asking about it directly, usually phrased as “how do you detect modification of third-party code in your application”. “We pin integrity hashes and enforce them at the browser with Integrity-Policy” is a materially better answer than “we review our vendors”.
It pairs with, rather than replaces, an SBOM: the SBOM tells you what you depend on, the integrity policy makes sure what ships is what you approved.
Where it maps for compliance
- NIS2 Article 21(2)(d), supply chain security, and 21(2)(g), basic cyber hygiene.
- ISO/IEC 27001:2022 A.5.21 (managing ICT supply chain) and A.8.28 (secure coding).
- DORA Article 28, ICT third-party risk, plus Article 6.
How to check it
curl -sI https://yourdomain.com | grep -i "integrity-policy"
A SaaSFort scan distinguishes three states, because they mean different things operationally: enforced, report-only, and absent. Report-only is progress, not protection.
The short version
SRI is a per-tag promise that degrades. Integrity-Policy is a page-level rule that does not.
Start with Integrity-Policy-Report-Only, use the reports as your inventory, then enforce.
Ready to put this into practice?
Two ways to start — pick what fits. Free Scan if you want to see your security grade in 60s with no commitment. Free 14-day Growth trial if you're ready to monitor multiple domains, export NIS2 reports, and download Deal Reports — no credit card required.
No credit card · Cancel anytime · GDPR-ready · EU-hosted