Sort every vendor script into two groups. Analytics tags only send data about what visitors do, so many can move to a server-side collector with a fixed set of fields. User interface tags change what the visitor sees, so they must run in the browser. OWASP uses this split.
The two types
The OWASP Third Party JavaScript Management Cheat Sheet divides vendor tags into user interface tags and analytic tags.
User interface tags have to execute on the client because they change the DOM: they display a dialog or image, or change text. Examples on a store include chat widgets, popups, review stars, recommendation carousels and personalization banners.
Analytic tags send information back to a marketing database: what action the user took, browser details, location and page details. Examples include page view counters, conversion events and ad attribution pings.
Why the split matters for risk
OWASP states that user interface tags cannot be made secure using the data layer architecture, because their function is to change the interface, not to send data about user actions. For analytics that do not need browser execution, it suggests sending a fixed event schema through a collector you control and running vendor integrations server-side.
It also adds a caution: server-side tagging complements rather than replaces client-side collection, and you should audit the scripts actually loaded before claiming only first-party code executes.
| Property | UI tags | Analytics tags |
|---|---|---|
| Needs the browser | Yes | Often not |
| Can change the page | Yes | Should not |
| Can move server-side | No | Often yes |
| Main risk | Code runs in the page with full access | Data leaves to a third party |
| Best control | Isolate, restrict pages, review code | Fixed fields, filtering, server collector |
How to sort your list
- Open your tag register or capture the live page.
- For each tag, ask: does it change anything the visitor sees? If yes, it is a UI tag.
- If it only reports, ask whether it truly needs browser access or can receive events from your server.
- Note the pages each one runs on.
- Flag any tag that does both, which is common with all-in-one marketing suites.
What to do with each group
UI tags. Keep them off checkout and account pages where you can. Where they must run, consider an isolated frame with the sandbox attribute, a Content Security Policy and a pinned, hashed file. Review the code or the vendor's change process.
Analytics tags. Define the data layer fields and send only those. Let a server-side collector forward them. Do not let a tag read URL parameters or form values directly. The earlier post on whether server-side tagging reduces script risk goes deeper.
Revisit after a platform change
A new storefront or a theme change can alter which tags run where. Re-sort the list after any redesign, and when a vendor adds a feature that changes its tag from reporting to display.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each entry can be grouped and tagged with an owner.
Where Safeguard fits
Safeguard's SBOM and dependency scanning covers packages in your build. For vendor tags, the sorting above is a manual review that feeds your register. A free scan is at gold.safeguard.sh/scan.
Quick check
Can a chat widget move server-side?
No. It changes what the visitor sees, so it must run in the browser. Limit where it loads instead.
Does moving analytics server-side remove all browser risk?
No. Other scripts may still load. Audit what actually runs on the page after any change.
Sources
Last reviewed: 19 October 2026.
