Notifications
Clear all
Topic starter
19/08/2026 3:33 pm
TL;DR: Browser-side controls are becoming a governance issue, not just a web performance issue: Jscrambler’s case study shows how third-party scripts, marketing tags, and dynamic payment pages complicate PCI DSS 6.4.3 and 11.6.1 compliance for large enterprises. The real challenge is continuous visibility and control over client-side data flows, not simply script blocking.
NHIMG editorial — based on content published by Jscrambler: Marriott Vacations Worldwide Secures the Browser with Jscrambler
Questions worth separating out
Q: What breaks when third-party scripts are not governed on payment pages?
A: When scripts are not governed, the browser becomes an uncontrolled access layer.
Q: Why do browser-side controls matter for PCI and privacy programmes?
A: They matter because sensitive data can be exposed before it reaches servers, logs, or network inspection.
Q: How do security teams know if agent governance is actually working?
A: It is working only if the team can answer three questions quickly for any agent: what it can reach, what it did recently, and whether that behaviour matches intent.
Practitioner guidance
- Inventory every script with data access Build and maintain a living inventory of first-party and third-party scripts on payment, login, and account pages.
- Fence sensitive form fields at runtime Apply field-level controls to block unauthorised access to payment and identity inputs, especially on pages that change frequently or rely on marketing tags.
- Route script alerts into security operations Send client-side integrity events into SIEM workflows so anomalous script behaviour, header changes, or data access attempts can be triaged alongside other security signals.
What's in the full article
Jscrambler's full case study covers the operational detail this post intentionally leaves for the source:
- How Marriott Vacations Worldwide mapped 160 card data flows across six entities and discovered every payment page
- How the Webpage Integrity workflow handled approvals, monitoring, and low-noise alerting in a lean compliance team
- How form fencing, agent injection, and SIEM integration were configured for sensitive pages and exceptions
- How PCI DSS requirements 6.4.3 and 11.6.1 were met in a dynamic, marketing-heavy web environment
👉 Read Jscrambler's case study on browser-side PCI control and script integrity →
Browser-side data governance in web apps: what practitioners need to know?
Explore further
19/08/2026 4:15 pm
Browser-side governance is now part of identity governance. If third-party scripts can read payment fields or browser storage, the organisation has extended trust to unmanaged non-human code. That creates an access problem, not just a web integrity problem. NHI governance patterns, especially inventory, approval, and lifecycle control, are directly relevant here, and the practitioner conclusion is to treat client-side execution as a governed identity surface.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% having only partial visibility, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who is accountable when a third-party script exposes customer payment data?
A: Accountability sits with the organisation operating the checkout, even when a third party supplied the script or tag. PCI obligations do not transfer with outsourcing. Security, compliance, and product teams need explicit ownership for script approval, monitoring, and incident response because the browser is still part of the organisation’s control boundary.
👉 Read our full editorial: Browser-side data governance and PCI control gaps in web apps
