The agency and the client should agree on one owner for third-party scripts, keep a written list of every script and why it is there, and use Subresource Integrity on files that do not change. Marketing tags added through a dashboard are the usual gap.
Third-party scripts run in the visitor's browser with the same access as your own code. A chat widget, an analytics snippet or a font loader is not passive.
Why scripts need an owner
Clients add scripts too. A marketing person pastes a tag into a theme setting, and a year later nobody knows what it loads. If that source is compromised, every page that loads it is affected. MDN describes the risk: a site relying on a CDN or other third party to host a resource is exposed if an attacker gains control of that host.
What SRI does
MDN explains that Subresource Integrity lets browsers verify that fetched resources, for example from a CDN, have not been manipulated. You supply a cryptographic hash that the fetched file must match. If the file changes, the browser refuses it.
This works for static files such as a pinned library version. It does not fit scripts that change by design, such as many tag managers and analytics loaders, because the hash would break. For those, SRI is the wrong tool and you need review and monitoring instead.
A simple decision table
| Script type | SRI possible | What to do instead or as well |
|---|---|---|
| Pinned library from a CDN | Yes | Add integrity hash, or self host |
| Analytics loader that updates itself | No | Review the vendor, limit what it can access |
| Tag manager container | No | Restrict who can publish changes, log changes |
| Chat widget | No | Load only on pages that need it |
| Fonts and icons | Often | Self host where practical |
Build the list
- Open the site with browser developer tools and list the domains that serve scripts.
- Match each to a reason and an owner.
- Remove those with no owner or no reason.
- Record the list in the handover document.
- Review it each quarter, and after any marketing campaign launch.
Self hosting as an option
If a library does not change often, hosting it yourself removes a third party from the page. You then own the update, so add it to the inventory and the patch routine like any other dependency.
Agree on who publishes
For tag managers, limit publish rights to named people, require review for changes and keep the history. That turns an invisible change channel into a visible one.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a list of components with versions makes review possible; the script list does the same job for the browser side.
Safeguard's free scan covers dependencies in a project repository, so script tags loaded from outside the repository need the manual list above.
Quick check
Does SRI work for every external script?
No. It needs a file that does not change, because the hash must match exactly. Self updating loaders cannot use it.
Who should own the script list?
One named person on the client side and one on the agency side, written into the handover.
Sources
Last reviewed: 19 October 2026.
