Notifications
Clear all
Topic starter
20/08/2026 5:42 pm
TL;DR: A governance gap spans e-commerce, healthcare, media, and travel, as 97% of organisations know JavaScript tags collect sensitive data, yet only 13% feel confident they know what those tags collect and 26% believe they leak data to others, according to Jscrambler. The practical issue is not just script security but uncontrolled client-side data access, where visibility and trust boundaries are weaker than most programmes assume.
NHIMG editorial — based on content published by Jscrambler: analysis of JavaScript tag data leakage and client-side protection
By the numbers:
- 97% of organisations are aware that JavaScript tags collect private and sensitive data.
- Only 13% of organisations are confident that they understand what information these tags collect.
- Only 26% are aware that these tags leak their private user data to other organisations.
Questions worth separating out
Q: How should security teams govern third-party JavaScript on customer-facing pages?
A: Treat third-party JavaScript as a controlled data access path, not just a website dependency.
Q: Why do browser scripts create data leakage risk even when they are legitimate?
A: Legitimate scripts still run with access to page content, user input, and browser state.
Q: What breaks when organisations rely only on script integrity checks?
A: Integrity checks confirm that code matches an approved version, but they do not prove the code is behaving safely.
Practitioner guidance
- Inventory all third-party scripts and tag dependencies Build a living register of every script loaded on customer-facing pages, including source domain, business purpose, data access scope, and owner.
- Enforce runtime controls on high-risk page journeys Use client-side protections that can block suspicious script behaviour, detect tampering, and alert on unexpected data handling in real time.
- Separate approved functionality from approved behaviour Do not assume a script is safe because it is business-approved.
What's in the full article
Jscrambler's full article covers the operational detail this post intentionally leaves for the source:
- Sector-specific examples of e-commerce, healthcare, media, and travel data leakage scenarios
- Detailed prevention steps for suspicious script activity, library integrity checks, and third-party blocking
- Implementation discussion for obfuscation, runtime defence, and continuous monitoring in client-side protection
- PCI DSS v4.0 context for browser-side controls on payment pages
👉 Read Jscrambler's analysis of JavaScript tag data leakage and client-side risk →
JavaScript tag leakage: what IAM and security teams are missing?
Explore further
20/08/2026 6:26 pm
Client-side scripts now function as unmanaged access pathways, not just page features. When organisations embed third-party JavaScript, they are delegating visibility into user behaviour, form input, and transaction context. That delegation sits awkwardly beside conventional IAM and privacy controls, which usually stop at the server or application boundary. The governance failure is treating browser scripts as convenience tooling rather than as actors with data access consequences. Practitioners should classify high-risk tags as controlled access paths, not optional marketing dependencies.
A question worth separating out:
Q: Who is accountable when a third-party tag leaks customer data?
A: Accountability usually sits with the organisation that chose to embed the tag and failed to govern its behaviour. Regulators and auditors will look for ownership, consent controls, data-minimisation decisions, and evidence of monitoring. If the script touches payment or personal data, the business must be able to show who approved it, why it was needed, and how it was supervised.
👉 Read our full editorial: JavaScript tag risk is outpacing visibility and data governance
