A tag manager is usually the hardest to control, because marketing can change what runs without a code release. Inline vendor code is the easiest to review but goes stale. A direct script request sits between them. Which is riskiest depends on who can change the code and how fast.
The three setups
The OWASP Third Party JavaScript Management Cheat Sheet describes three basic deployment mechanisms for vendor tags, which can be combined.
Vendor JavaScript on the page. The vendor hands you the code and you paste it into your page. You must review it yourself, which OWASP notes is often difficult because the code is commonly obfuscated.
JavaScript request to the vendor. A line on your page requests a file from the vendor's server on every visit. Whatever the vendor serves that day runs in the visitor's browser.
Indirect request through a tag manager. Your page loads a container from a tag manager, and the container returns whatever tags your team configured. Non-technical staff can change those through a graphical interface.
How they compare
| Question | Inline | Direct request | Tag manager |
|---|---|---|---|
| Who can change what runs? | Your developers | The vendor | Vendor and anyone with publish access |
| How fast can it change? | At your next release | Instantly | Instantly |
| Can you review the code? | Yes, if readable | Only by fetching it | Only through the interface or by proxying |
| Does a hash help? | Not needed | Yes, with a pinned file | Limited, since the container changes |
| Where is the audit trail? | Your repository | Vendor release notes | Tag manager history |
OWASP's own summary of the problem is that you can only see the code if you proxy the requests or get access to the interface. It is also instantly deployable: as soon as a file changes at the vendor, or is modified in the tag manager, the next browser call gets the new version.
What to do about each
For inline code, treat it like any dependency. Put it in version control, review it, and set a reminder to refresh it, because it will not update itself.
For direct requests, use a versioned URL and a Subresource Integrity hash where the vendor supports it, and a Content Security Policy that lists the allowed source.
For a tag manager, restrict who can publish, require a second person to approve changes on sensitive pages, and review changes the way you review application code. OWASP suggests limiting tag types, for example disabling custom HTML tags and custom JavaScript, and having the tag manager only read values from a data layer. See the related post on reviewing tag manager changes like application code.
A simple decision rule
Keep the most sensitive pages, such as checkout and account pages, on the setup you can review best. Move tags that need the freedom of a tag manager to pages where a mistake costs less. If a vendor insists on a tag manager for checkout, ask why.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how every component gets an entry, which is the habit you want for vendor scripts too.
Where Safeguard fits
Safeguard's SBOM and dependency scanning covers inline or bundled code that arrives as packages in your repository. Scripts fetched at run time, including those from a tag manager, need the page-level controls above. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a tag manager unsafe by default?
No. It is a powerful tool that needs access control and review. The risk is unreviewed publishing, not the product category.
Is inline vendor code always safest?
It is easiest to review, but it can go stale and miss vendor fixes unless you refresh it on a schedule.
Sources
Last reviewed: 19 October 2026.
