Almost none. On pages behind login, allow only scripts you host or have reviewed and pinned, sandbox anything else in an iframe, restrict the tag manager and send analytics through a collector you control. A third-party script runs with the same access as your own code and can see what the page shows.
Why portals are different
A marketing page and a patient portal have different risk. A script on the portal can read what is on screen, including names, appointment details and messages, and it can send that anywhere it likes. A tag manager lets non-engineers add such scripts without a code review.
The OWASP Third Party JavaScript Management Cheat Sheet gives specific controls. It suggests loading vendor code from another domain inside an iframe, which keeps it away from the host page's DOM and cookies, and using the sandbox attribute to restrict it. It also advises Subresource Integrity with crossorigin set to anonymous, and notes that tag-manager delivered code is hard to pin because content can change without a deployment.
Allowlist by page type
| Page type | Third-party scripts |
|---|---|
| Public marketing | Reviewed, limited |
| Sign in and sign up | Minimal, ideally none |
| Behind login | None by default |
| Payment or identity steps | None |
Write this table into your engineering standards and check it in code review.
Controls to apply
- Keep a written inventory of every script, who owns it and why it is there.
- Where a vendor script must remain, load it in a sandboxed iframe from a separate domain and pass only the values it needs through postMessage, checking the message origin.
- Add Subresource Integrity hashes where the vendor allows it.
- In the tag manager, disable custom HTML and custom JavaScript tags, limit tags to data layer values and require two-factor authentication.
- Treat tag manager publishing like a production deployment: review changes as application code.
- Define a host-controlled data layer with only the values you choose to expose.
- Route analytics through a collector you control, with a fixed event schema.
The cheat sheet notes a data layer is not a sandbox, so the data layer alone does not isolate scripts running in the page.
Check what is really loading
Open a portal page in a browser with network inspection and list every domain contacted. Compare it with the inventory. The difference is your unknown risk. Repeat after each marketing change.
Where Safeguard fits
Safeguard scans the packages in your own front end, and its gates can require review of new dependencies. Auditing which third-party scripts load at runtime is a separate task, and the steps above cover it. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is Subresource Integrity enough on its own?
No. It pins a file, but it does not help with tag manager content that changes, and it does not limit what an approved script can do.
Who should approve a new portal script?
An engineer and a privacy owner together, with the data flow written down.
Sources
Last reviewed: 19 October 2026.
