A script loaded without subresource integrity
A script loaded without a hash pin. When subresource integrity protects a file you host, when it breaks a vendor CDN, and what to do instead.
Last reviewed September 2026.
What the finding is saying
The scanner saw a <script> with a src and nointegrity attribute. The file still loaded. The tag may still be firing. This note does not mean the script was tampered with. It means the browser was not given a hash to check against.
What SRI does
Subresource Integrity is a hash on the tag. The browser downloads the file, hashes it, and refuses to run it if the bytes do not match. That stops a CDN compromise from executing on your page — and it also stops a routine vendor release, because the new file has a new hash.
That second case is why almost every store’s report lists gtag/js, a pixel loader, or a tag-manager container as missing SRI. Those files are supposed to change. Pinning them would take the tag down the next time the vendor published.
What you can do
Pin scripts you host yourself and do not replace without a deploy: a first-party analytics wrapper, a theme file, a file you copied onto your own origin. Generate the hash from the exact bytes you serve. If you change the file, change the attribute in the same change.
Leave vendor files that change on their own. Google, Meta, and most pixels will keep appearing here. Pinning those loaders will break tracking the next time the vendor publishes a new file. You can leave them.
If the file sits on a payment page and you need a written authorization rather than a hash, that is PCI 6.4.3 and Manifest, not an SRI attribute ongtag/js.
Related
A missing Content-Security-Policy is the other common note on the same report.What that header is, and how stores add it.
Confirm it with a scan
Four page types, a real browser, no account. A scan will not fix the tag. It will tell you whether it is firing now.