# Integrity-Policy (/en/docs/web-security/policies/integrity-policy)



Integrity-Policy lets a site require that every resource of a given type carries
valid Subresource Integrity (SRI) metadata. If a script is loaded without a correct
`integrity` value, for example because a CDN asset was swapped or tampered, the
browser blocks it or reports it. It turns SRI from a per-tag opt-in into a policy
you can enforce site-wide, taking over the goal of the abandoned CSP
[require-sri-for](/en/docs/web-security/policies/content-security-policy/directives/require-sri-for)
directive.

<Callout type="info" title="Limited availability">
  Integrity-Policy is new but no longer single-engine. Enforcement for the `script` destination now ships in all three engines (Chrome, Firefox, and Safari); Firefox delivers reports to endpoints only in recent versions, and the `style` destination is behind a Firefox pref only. See Browser support below.
</Callout>

Start in Report-Only, with the endpoint name declared in
[`Reporting-Endpoints`](/en/docs/web-security/reporting-api/headers/reporting-endpoints):

```http
Integrity-Policy-Report-Only: blocked-destinations=(script), endpoints=(integrity-endpoint)
```

## How Integrity-Policy works [#how-integrity-policy-works]

You declare which resource destinations must be integrity-protected. The browser
then requires a valid `integrity` attribute on every load of that type and blocks
(or, in Report-Only, reports) any that lacks one. So instead of remembering an
`integrity` attribute on every tag, you state the requirement once.

## How to configure Integrity-Policy [#how-to-configure-integrity-policy]

```http
Integrity-Policy: blocked-destinations=(script)
```

| Directive              | Status          | Meaning                                                                                                                                                                               |
| ---------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `blocked-destinations` | ✅ Good          | Required. The destinations that must be integrity-protected. `script` is cross-browser (Chrome, Firefox, and Safari); the `style` value is 🧪 Experimental, Firefox-behind-pref only. |
| `sources`              | 🧪 Experimental | Optional. Where integrity is required; `inline` (the only value, and the default) means the `integrity` attribute.                                                                    |
| `endpoints`            | ✅ Good          | Optional. Reporting endpoint names declared in `Reporting-Endpoints`. Firefox delivers endpoint reports only in recent versions.                                                      |

## Report-only mode [#report-only-mode]

```http
Reporting-Endpoints: integrity-endpoint="https://<Endpoint-ID>.report.centralcsp.com"
```

This declares the `integrity-endpoint` name the opening example references.
Report-Only lists every script that lacks valid SRI without blocking it, which is
the safe way to discover what is not yet hashed before you enforce.

## What it protects against [#what-it-protects-against]

Supply-chain tampering: a modified or swapped CDN script, an injected asset, or a
resource fetched in `no-cors` mode without integrity protection. SRI catches the
swap because the hash no longer matches; Integrity-Policy makes that protection
mandatory rather than per-tag.

## Insecure configurations to avoid [#insecure-configurations-to-avoid]

Enforcing before you know which scripts carry SRI will block legitimate but un-hashed
ones and break the page. Run Report-Only first, and add the `integrity` attribute (or
remove the dependency) for everything that shows up.

## Known bypasses and limitations [#known-bypasses-and-limitations]

Currently scoped to scripts in practice: the `style` destination exists in the spec
but ships only behind a Firefox pref. Earlier Firefox versions enforce the policy but
log to the console instead of delivering endpoint reports. And it pairs with rather
than replaces a strong CSP; the two cover different parts of the script-trust problem.

## Risks [#risks]

A roll-out without an inventory of which scripts already carry SRI can take the page
down. Build that inventory first, then enforce.

## Recommendation [#recommendation]

```http
Integrity-Policy-Report-Only: blocked-destinations=(script), endpoints=(integrity-endpoint)
```

Start in Report-Only, the roll-out path [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Integrity-Policy)
recommends: watch which scripts show up without valid
[Subresource Integrity](/en/docs/web-security/other/subresource-integrity), add the
missing hashes (the [SRI generator](/tools/sri-hash) computes them), then switch
the header to `Integrity-Policy` once the reports go quiet.

## Reporting [#reporting]

Integrity-Policy selects its reporting endpoints with the `endpoints=()` directive,
not the `report-to=` parameter the other policies use, with the names declared in
`Reporting-Endpoints`. The browser emits the
[integrity-violation report](/en/docs/web-security/reporting-api/reports/integrity-violation). Pair
it with the CentralCSP [script inventory](/en/docs/platform/features/script-inventory)
and the [SRI generator](/tools/sri-hash) to know and fix what lacks integrity.

## Browser support [#browser-support]

Defined in the SRI spec; limited availability, but the `script` destination is now
enforced in all three engines: Chrome, Firefox, and Safari. Firefox delivers reports
to endpoints only in recent versions (earlier versions logged to the console). The
`style` destination is behind a Firefox pref only.

## FAQ [#faq]

### What does Integrity-Policy do? [#what-does-integrity-policy-do]

Integrity-Policy lets a site require that every resource of a given type carries
valid Subresource Integrity metadata. If a script loads without a correct
`integrity` value, because a CDN asset was swapped or tampered with, the browser
blocks or reports it. It turns SRI from a per-tag opt-in into a requirement you
enforce site-wide.

### What is the difference between Integrity-Policy and Subresource Integrity? [#what-is-the-difference-between-integrity-policy-and-subresource-integrity]

SRI is a per-tag opt-in: you add an `integrity` attribute to each script or style
tag you want verified, and the browser checks the hash on that tag alone.
Integrity-Policy enforces SRI site-wide, requiring a valid `integrity` value on
every load of a declared destination, so nothing slips through un-hashed.

## See also [#see-also]

* [Subresource Integrity (SRI)](/en/docs/web-security/other/subresource-integrity)
* [require-sri-for](/en/docs/web-security/policies/content-security-policy/directives/require-sri-for), the removed CSP predecessor
* [Integrity-Policy explained (guide)](/en/blog/integrity-policy-explained)
* [integrity-violation report](/en/docs/web-security/reporting-api/reports/integrity-violation)
* [csp-hash report](/en/docs/web-security/reporting-api/reports/csp-hash)
* [Reporting-Endpoints header](/en/docs/web-security/reporting-api/headers/reporting-endpoints)
* [Integrity-Policy monitoring in CentralCSP](/en/docs/platform/monitoring/integrity-policy)

## Sources [#sources]

* [MDN, Integrity-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Integrity-Policy)
* [W3C, Subresource Integrity Integrity-Policy](https://w3c.github.io/webappsec-subresource-integrity/#integrity-policy-section)