Keep third party marketing tags off pages where a script could see credentials, payment details or sensitive personal data, such as login, password reset, payment and account settings pages. Where a tag is truly needed there, run it in a tightly controlled way and review it as code.
Why page choice matters
A tag that runs on a page can read what is on that page. OWASP's third party JavaScript guidance lists three risks: loss of control over client changes, arbitrary code execution, and disclosure of data to third parties. The more sensitive the page, the more each of those costs. A homepage tag that goes wrong is a bad day. A tag that goes wrong on a login form is an incident.
This is a guide to risk, not a rule from a regulator. Your own obligations depend on your sector and law, so check with counsel.
A decision table
| Page type | Default stance | Why |
|---|---|---|
| Public marketing and blog pages | Tags allowed with review | Little sensitive data on the page |
| Pricing and sign up start | Allowed, narrow triggers | Intent data, but no secrets |
| Login and password reset | No marketing tags | Credentials typed here, tokens in URLs |
| Payment and checkout | Minimal, controlled scripts only | Card data theft by injected script is a known pattern |
| Account and settings | No marketing tags by default | Personal details on screen |
| Health, finance or children's content | Strictest review, often none | Higher sensitivity and stricter rules in many places |
| Internal tools and admin | No marketing tags | No reason for third parties to be there |
OWASP's page mentions payment data theft through injected JavaScript, so payment pages deserve the tightest approach. See payment page scripts and SAQ A.
How to enforce the split
- Separate containers or environments. Use one container for public pages and none, or a minimal one, for sensitive areas.
- Trigger conditions. Exclude sensitive paths in every trigger, with a block list that is checked on release.
- CSP per area. A stricter policy on sensitive paths stops tags from loading even if a trigger slips.
- Server side events. Where a conversion on a sensitive page matters, send a minimal event from your server instead of loading a vendor script.
- Test. Walk each sensitive flow with the network panel open and confirm no third party requests appear.
Handling the conversion argument
Marketing teams often want to measure checkout or sign up completion. You can usually measure the step before and the confirmation after without running a vendor script during entry of sensitive details. A thank you page with a generic event gives the result without giving a script a view of the form.
Be careful with the URL of the thank you page too. If it carries an order number or email, the tag will carry it out. See personal data in URLs sent to analytics.
Make it a standing rule
Write the table into your tag policy and review it when the site structure changes. New pages inherit tags by default in many setups, so the rule has to be a block list that someone owns.
Quick check
Is it safe to run analytics on a login page?
Avoid it. If you must measure it, count visits server side and keep third party scripts off the page.
Can a strict CSP replace the page rules?
It adds a second layer. Keep both, since a tag allowed by policy can still read the page.
Where Safeguard fits
Safeguard's policies and gates can hold code changes behind review, and dependency scanning plus SBOM cover shipped packages. Try the free scan.
Sources
Last reviewed: 19 October 2026.
