# How to fix an Unsafe Implementation of Subresource Integrity finding (/en/blog/fix-sri-security-finding)





SecurityScorecard scanned your site and opened a finding named "Unsafe Implementation of Subresource Integrity (SRI)" under its Application Security factor, rated High severity (issue key `unsafe_sri_v2`). It means the scanner found scripts loading from external hosts without a correct `integrity` attribute (and often without the `crossorigin` that goes with it), so the browser is taking those files on trust. The fix is not complicated, it is just a workflow: find which scripts lack SRI, generate the right hashes, and roll the change out safely so you do not break the page.

The short version: list every external script and check which ones are missing a valid `integrity`/`crossorigin` pair, generate the hash for each one, add it, and verify in report-only mode before you rely on it. This post walks that workflow end to end.

## What the finding actually means [#what-the-finding-actually-means]

[Subresource Integrity (SRI)](/en/blog/subresource-integrity-sri) lets the browser verify that a script it fetched matches a hash you supplied, and refuse it on a mismatch. SecurityScorecard flags the absence of that protection: a `<script src>` pointing at a CDN or third-party host with no `integrity` attribute, or one with `integrity` but no `crossorigin` (which silently fails for cross-origin files).

One point to be clear about, because it trips people up: adding a Content Security Policy does not clear this finding. Only adding an `integrity` attribute, with `crossorigin`, to each affected script or style tag, or self-hosting the resource so it is served same-origin, resolves it. A CSP controls which origins can load, not whether a loaded file was tampered with, so it is the wrong tool for this specific finding.

The underlying risk is real either way. If the third-party host is compromised and serves altered code, an unhashed script runs the tampered file without complaint. That is the formjacking and supply-chain scenario SRI exists to stop.

## 1. Find the scripts that lack integrity [#1-find-the-scripts-that-lack-integrity]

You cannot hash what you have not inventoried. Start by listing every external script the page loads and marking which ones are missing a correct `integrity`/`crossorigin` pair.

A quick scan with the [security headers scanner](/tools/security-headers) shows the page's header posture, and the [script inventory](/platform/supply-chain) builds the full list of scripts running across your pages from CSP hash reports, including third-party ones that a single page scan misses. If you have an [Integrity-Policy](/en/docs/web-security/policies/integrity-policy) running in report-only mode, its `integrity-violation` reports name each script that lacks valid SRI directly, which is the precise list you need.

Watch for the cross-origin trap while you audit: a script can have an `integrity` attribute and still be unprotected if `crossorigin` is missing, because the browser cannot read the bytes to verify them.

```html
<script
  src="https://cdn.example.com/widget.js"></script>            <!-- [!code --] -->
<script
  src="https://cdn.example.com/widget.js"
  integrity="sha384-<digest>"
  crossorigin="anonymous"></script>                            <!-- [!code ++] -->
```

<img alt="Scripts reported as loading without integrity metadata" src="__img0" width="1359" height="388" />

## 2. Generate the hash for each script [#2-generate-the-hash-for-each-script]

For each script on the list, generate its hash. Paste the URL into the [SRI generator](/tools/sri-hash), which produces the full `integrity` value (SHA-256, SHA-384, and SHA-512) from the exact file the host serves. Use SHA-384 or SHA-512; if you list more than one algorithm, the browser checks against the strongest one present.

Pin a versioned URL, not a "latest" one. SRI does not auto-update, so a hash on a URL that always points at the newest build will break the moment the upstream file changes. Pin the version, hash that exact file, and update both together when you upgrade. The [SRI explainer](/en/blog/subresource-integrity-sri) and [how to generate an SRI hash](/en/blog/generate-sri-hash) cover the mechanics.

## 3. Roll it out in report-only first [#3-roll-it-out-in-report-only-first]

Adding hashes is safe per tag, but if you also want to enforce SRI across the whole site so the finding cannot come back, do it in report-only mode first. An `Integrity-Policy-Report-Only` header reports every script that still lacks valid integrity without blocking anything, so you confirm your coverage before you enforce.

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

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

Leave it running until no more scripts show up in the reports. Then drop the `-Report-Only` suffix to enforce. Enforcing before the report is clean would block legitimate but un-hashed scripts and take the page down, which is why report-only goes first.

## 4. Verify and rescan [#4-verify-and-rescan]

Once the hashes are in place and the report-only stream is quiet, rescan with the rating service (or the [security headers scanner](/tools/security-headers)) to confirm the finding clears. Keep the inventory and reporting on after that: the finding comes back the moment someone adds a new unhashed third-party tag, and an ongoing [script inventory](/platform/supply-chain) catches that change before the next scan does.

CentralCSP keeps that loop running, inventory of every script, integrity-violation reports, and alerting when a new or changed script appears, so the finding stays closed instead of reopening at the next audit. [Start free](/register) to inventory your scripts and watch for the next gap.

## Sources [#sources]

* [SecurityScorecard, Unsafe Implementation of Subresource Integrity (SRI)](https://support.securityscorecard.com/hc/en-us/articles/41067186972827-Unsafe-Implementation-of-Subresource-Integrity-SRI)
* [MDN, Subresource Integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity)

## Related [#related]

* [Subresource Integrity (SRI) explained](/en/blog/subresource-integrity-sri)
* [How to generate a Subresource Integrity (SRI) hash](/en/blog/generate-sri-hash)
* [Integrity-Policy reference](/en/docs/web-security/policies/integrity-policy)