Mostly no. Subresource Integrity pins a script to one exact hash, so any change makes the browser refuse it. A tag manager loader or analytics snippet is meant to change without your deploy, so a pinned hash either breaks the tag or gets removed. Use access control, tag limits and monitoring instead.
What SRI actually checks
You add an integrity attribute holding a hash, plus crossorigin="anonymous". The browser downloads the file, hashes it and compares. On a mismatch it returns a network error and the script does not run, according to MDN's SRI guide.
That is a strong guarantee for a file that never changes, such as a pinned version of a UI library. It is the wrong tool for a file whose whole job is to change.
Why tags break the model
A tag manager container is configuration that the vendor serves from a remote URL. Marketing staff can publish a new container version at any time, and the loader then runs the new tags. The OWASP Third Party JavaScript Management cheat sheet notes that remote containers can swap in new code without a deployment.
Analytics vendors also update their snippets. If you pin a hash and the vendor ships a fix, your page silently loses analytics, or worse, a developer removes the attribute to stop the alerts.
Even if you pin the loader file itself, the loader pulls further scripts that carry no hash of yours. SRI covers the first hop only.
What to do for scripts that must stay dynamic
| Control | What it gives you |
|---|---|
| Limit tag types | Disable custom HTML and custom JavaScript tags in the manager, as OWASP suggests |
| Restrict publishing | Few named publishers, two factor sign in, an approval step |
| Server side collection | Send events to your own endpoint and forward them, so fewer vendor scripts run in the browser |
| CSP with connect-src | Limits where a tag can send data (see the related post on CSP and exfiltration) |
| Change monitoring | Alert when the loaded file or container version changes |
OWASP also warns that a data layer is not a sandbox. Tags that read from it still run inside your page.
Where SRI still earns its place
Use SRI for static assets you control the version of: a framework file from a CDN at an exact version, a polyfill you have reviewed, a stylesheet. For these, a hash is cheap and the failure mode is loud.
A practical split is to pin everything that can be pinned, and put the remaining dynamic scripts on a short, reviewed list with an owner for each one. If you are starting from nothing, see how to add Subresource Integrity to scripts and stylesheets and your tag manager is a second deployment pipeline.
A short audit you can run today
- List every script URL a key page loads, including those added by other scripts.
- Mark each one as pinnable or dynamic.
- Add SRI to the pinnable ones.
- For each dynamic one, write down the owner, the data it can reach and how you would notice a change.
- Remove any tag nobody can justify.
Safeguard's SBOM and dependency scanning cover the npm packages that ship in your build, which complements this work for the code you bundle yourself. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does SRI work if the CDN file is minified differently each week?
No. Any byte change gives a different hash, so the browser blocks the file. Pin an exact version, not a floating alias.
Is the crossorigin attribute required with integrity?
Yes for cross-origin files. MDN says SRI requests must use CORS, and a request made without it will fail when integrity is present.
Sources
- MDN, Subresource Integrity: https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Subresource_Integrity
- OWASP, Third Party JavaScript Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html
Last reviewed: 19 October 2026.
