Notifications
Clear all
Topic starter
19/08/2026 3:31 pm
TL;DR: Marriott Vacations Worldwide says it achieved full compliance with PCI DSS v4 requirements 6.4.3 and 11.6.1 by using Jscrambler’s Webpage Integrity to control third-party scripts, improve visibility across payment pages, and reduce manual oversight in a complex browser environment, according to Jscrambler. The governance lesson is that client-side risk now sits squarely inside broader identity, access, and data control programmes, not just web security.
NHIMG editorial — based on content published by Jscrambler: Marriott Vacations Worldwide Secures the Browser with Jscrambler
By the numbers:
- Marriott Vacations Worldwide protected 160 card data flows across six distinct entities.
- The organisation has more than 15 unique codebases supporting the environment.
Questions worth separating out
Q: How should security teams control third-party scripts on payment pages?
A: Security teams should treat third-party scripts as runtime access subjects, not passive assets.
Q: Why do third-party scripts increase client-side risk in regulated web apps?
A: Third-party scripts can read form inputs, alter page behaviour, and move data outside the server-side control path.
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 every payment-page script path Build and maintain a script inventory that maps each third-party tag, owner, approval status, and page location across all payment flows.
- Tie browser events to security operations Send unauthorised script changes, blocked access events, and policy exceptions into the SIEM so analysts can triage them alongside other runtime alerts.
- Restrict third-party data access by default Apply allowlisting and deny-by-default rules so scripts only access the minimum data required for their function.
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 PCI DSS 4.0 requirements 6.4.3 and 11.6.1 to browser-side controls across its payment estate.
- What the Webpage Integrity workflow looked like for approvals, blocking, and exception handling in a live enterprise environment.
- How the team balanced marketing page changes with compliance evidence across more than 15 unique codebases.
- Why the organisation chose a runtime monitoring approach instead of relying only on CSP and SRI.
👉 Read Jscrambler's case study on browser-side PCI DSS v4 compliance →
Browser-side script control for PCI DSS v4 compliance: what changed?
Explore further
19/08/2026 4:14 pm
Browser integrity is now an access-control problem, not just a web-security problem. When third-party scripts can read payment fields or alter form behaviour, they are functionally exercising delegated access inside the session. That makes browser governance relevant to identity, privilege, and data protection teams, not only application security. Practitioners should treat client-side control as part of the access model.
A question worth separating out:
Q: What should teams do when business users can change payment pages outside IT?
A: They should introduce independent validation before publication, require rollback capability, and define who can approve client-side changes. When page ownership is fragmented, the control problem is governance, not just code review.
👉 Read our full editorial: Browser-side payment page integrity raises the bar for PCI control
