Notifications
Clear all
Topic starter
18/08/2026 2:23 pm
TL;DR: Client-side browser controls are now a PCI governance problem, not just a frontend security concern, as Marriott Vacations Worldwide used Jscrambler to meet PCI DSS requirements 6.4.3 and 11.6.1 while managing dynamic payment pages and third-party scripts. The broader lesson is that visibility, approval, and runtime control in the browser now sit inside the same governance perimeter as identity and data protection.
NHIMG editorial — based on content published by Jscrambler covering Marriott Vacations Worldwide’s browser integrity and PCI DSS compliance case study
By the numbers:
- The company reported 160 card data flows across six distinct entities.
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 dynamic web environments make browser security harder to manage?
A: Dynamic environments change faster than manual inventories can keep up.
Q: How do security teams know if browser integrity controls are working?
A: They should look for three signals: complete coverage of payment pages, low-noise integrity alerts, and a fast approval or revoke path when unexpected script changes appear.
Practitioner guidance
- Inventory all payment-bearing web pages Build and maintain a complete inventory of every browser flow that can touch card data, including brand sites, microsites, and dynamically generated pages.
- Govern third-party scripts with explicit approval paths Require named ownership, business justification, and security approval for each script or tag that can execute on payment pages, then remove unowned code.
- Set runtime revoke controls for client-side access Use a fast cut-off mechanism for scripts that overreach, so teams can block data access without breaking the full site experience.
What's in the full article
Jscrambler's full article covers the operational detail this post intentionally leaves for the source:
- How Webpage Integrity maps to PCI DSS 6.4.3 and 11.6.1 in practical browser environments
- The company’s internal workflow for handling approvals across multiple brands and codebases
- What the low-noise SIEM integration looked like in day-to-day operations
- How the “panic button” style revocation was used to cut off script access without degrading the site
👉 Read Jscrambler’s analysis of Marriott Vacations Worldwide’s browser integrity controls →
Client-side script control: are your browser controls keeping up?
Explore further
18/08/2026 3:14 pm
Client-side governance is now part of identity and access control for the browser. When third-party scripts can reach sensitive payment flows, the control question is no longer only what code is present, but what that code is authorised to see and do. That is an access problem as much as a web security problem, and it belongs inside the same governance model that teams use for privileged systems. Practitioners should treat browser trust as a scoped entitlement decision, not a static deployment choice.
A question worth separating out:
Q: Who should be accountable for client-side script risk in regulated environments?
A: Accountability should sit with shared ownership across security, compliance, application teams, and the business groups that introduce scripts. Security defines the control model, application teams manage deployment, and business stakeholders justify external code. Regulators and auditors care less about the org chart than whether clear approvals, monitoring, and evidence exist.
👉 Read our full editorial: Client-side script control is becoming a PCI governance issue
