Integrity-Policy is a response header that makes the browser block scripts or styles that have no integrity metadata, and block no-cors requests for them. It turns SRI from a habit into a rule. MDN lists it as limited availability, so use report-only first and keep other controls.
What it enforces
Subresource Integrity only protects tags that carry an integrity attribute. Anyone can add a new script tag without one, and nothing complains. Integrity-Policy closes that gap. Per MDN, when the header is set the browser:
- Blocks requests for the listed destinations that omit integrity metadata.
- Blocks requests made in no-cors mode.
Syntax
Reporting-Endpoints: integrity-endpoint="https://example.com/integrity"
Integrity-Policy: blocked-destinations=(script), endpoints=(integrity-endpoint)
| Key | Meaning |
|---|---|
| blocked-destinations | Required. The allowed values are script and style |
| sources | Optional. The only value is inline, which is the default |
| endpoints | Optional. Names of endpoints defined in Reporting-Endpoints |
A report arrives as JSON with type integrity-violation, the document URL, the blocked URL and the destination.
Why you might want it
If your team has already pinned its scripts, the header stops regressions. A developer who pastes a vendor snippet without a hash gets a blocked script in testing, not a quiet gap in production. It also pairs well with a strict CSP, which controls where scripts may come from, while Integrity-Policy controls whether they must be hash checked.
Why to go carefully
- MDN labels the feature as limited availability, meaning it is not supported across the most widely used browsers. Check the compatibility table for your audience.
- Scripts that must change, such as tag manager loaders, cannot carry a fixed hash. Blocking them breaks the site.
- Third party servers must send CORS headers for hashed cross-origin loads.
A rollout plan
- Inventory scripts and styles per page, see how to list every third-party script.
- Add integrity and crossorigin to everything that can be pinned.
- Send the report-only variant first. MDN's SRI guide recommends starting with report-only, then enforcing once no violation reports appear.
- Triage reports. Pin, replace or remove each flagged resource.
- Switch to the enforcing header for pages that are clean.
- Keep the reports flowing so new violations reach an owner.
What it does not do
It does not check what a script does, only that its bytes match a hash someone reviewed. A reviewed hash of a malicious file still passes. It does not cover inline script content or scripts that your own code adds after loading unless those requests carry integrity too. Pair it with CSP and dependency scanning.
Safeguard scans the npm dependencies in your builds and can flag known advisories, which addresses the part a hash cannot judge. Try the free scan at gold.safeguard.sh/scan.
Quick check
Does Integrity-Policy replace CSP?
No. CSP limits sources and inline code. Integrity-Policy requires hashes on listed resource types. They answer different questions.
Can I try it without breaking users?
Yes. Use the report-only variant first and read the violation reports before enforcing.
Sources
- MDN, Integrity-Policy header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Integrity-Policy
- MDN, Subresource Integrity: https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Subresource_Integrity
Last reviewed: 19 October 2026.
