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.
At a glance
What this is: This case study shows how Marriott Vacations Worldwide met PCI DSS v4 browser-side script controls by improving visibility and governance over third-party scripts on payment pages.
Why it matters: It matters because payment-page integrity is now part of access and data protection governance, not just web development hygiene, and identity teams increasingly need to account for third-party execution paths.
Context
Browser-side payment protection is about controlling what executes in the customer’s session before card data is submitted. In practice, the risk comes from third-party scripts, marketing tags, and dynamic page changes that can alter payment-page behaviour without the same change control used in back-end systems.
For IAM, PAM, and broader governance teams, the important issue is that these client-side dependencies create an execution boundary that is not captured by traditional identity lifecycle controls. The article shows a typical enterprise pattern rather than an edge case: distributed ownership, limited visibility, and compliance pressure all converge in the browser.
Key questions
Q: Where does browser-side payment control fail in practice?
A: It fails when teams focus on the payment form but ignore the scripts and tags that execute around it. In dynamic environments, third-party code can change browser behaviour, access sensitive data, or drift out of scope after deployment. The control gap is not only technical; it is also ownership, review, and continuous monitoring across the page lifecycle.
Q: Why do third-party scripts complicate PCI DSS compliance so much?
A: Third-party scripts complicate compliance because they extend trust outside the merchant’s direct codebase and can change without the merchant’s release process. Teams must justify each script, verify integrity, and watch for runtime tampering. That makes ownership, inventory accuracy, and change visibility as important as the payment application itself.
Q: What signals show that client-side compliance is drifting?
A: Common signals include uncatalogued payment pages, frequent script changes, inconsistent header integrity, and reliance on manual reviews to explain what is running in production. When those conditions exist, the organisation is likely relying on point-in-time checks rather than continuous assurance, which is fragile in fast-changing web estates.
Q: Which PCI DSS v4 controls are most relevant to browser-side script governance?
A: The controls most directly tied to browser-side script governance are the ones covering script integrity and change detection on payment pages. Practitioners should map their web execution controls to the PCI requirements that drive continuous monitoring, evidence collection, and approval discipline across the browser environment.
Technical breakdown
Why payment-page integrity now includes client-side execution control
PCI DSS v4 requirements 6.4.3 and 11.6.1 reflect a shift from server-only hardening toward monitoring what happens in the browser itself. Client-side script integrity matters because third-party tags can read, modify, or relay page data before the payment form is submitted. Traditional CSP or SRI controls help, but they do not always provide the operational governance, approval flow, or continuous monitoring needed in fast-changing commerce environments. The control problem is not just blocking scripts. It is ensuring that approved scripts, headers, and page behaviour stay aligned as pages change across brands and business units.
Practical implication: Treat browser-side integrity as part of payment control design, not as a front-end afterthought.
How third-party scripts create governance gaps in dynamic web environments
Third-party scripts are effectively delegated execution paths. They are often introduced by marketing, sales, or product teams outside the core security workflow, which makes inventory, approval, and change tracking difficult. Once pages are highly dynamic, the organisation can lose sight of where card data is collected, which scripts are present, and which pages are in scope. That creates a governance gap similar to unmanaged access paths in identity programmes: the issue is not only the script itself, but who can introduce it, under what review, and with what ongoing visibility. In regulated payment environments, that becomes an assurance problem as much as a technical one.
Practical implication: Map ownership, approval, and monitoring for every third-party script that can touch payment flows.
Why continuous monitoring matters more than one-time compliance checks
The article shows why one-off audits are not enough in browser security. A page can be compliant at one point in time and drift out of control as marketing tags, content updates, and script dependencies change. Continuous monitoring helps detect unauthorized changes, header integrity issues, and unexpected script behaviour before they affect payment data. This is especially relevant where small compliance teams support multiple entities, because manual review does not scale with the number of web properties or the pace of change. In other words, compliance evidence must be produced by the control itself, not assembled manually after the fact.
Practical implication: Use continuous browser monitoring to sustain evidence of control between audit cycles.
Threat narrative
Attacker objective: The objective is to access or manipulate payment-page data through trusted browser-side execution paths.
- Entry occurs when a third-party script or marketing tag is introduced into a payment page through normal business change channels.
- Credential or data access follows when that script can observe, modify, or transmit browser-side payment information before submission.
- Impact is realised when uncontrolled client-side execution undermines payment-page integrity, increasing the risk of data exposure and compliance failure.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Browser-side integrity is now a governance problem, not only a web security problem. When third-party scripts can alter payment-page behaviour, the control boundary extends into browser execution and page ownership. That means compliance teams, web teams, and identity governance teams all have a stake in approval, inventory, and monitoring. Practitioners should treat payment-page integrity as part of broader control assurance, not a narrow front-end control.
Delegated script execution creates a client-side trust gap. Organisations often know which business team asked for a tag, but not whether the tag remains necessary, unchanged, or suitably constrained. That gap is especially visible in dynamic marketing environments where pages and scripts evolve faster than review cycles. Practitioners need a named control owner for every script path that can reach card data.
Client-side drift: approved pages can become non-compliant after ordinary content changes, because the browser environment changes faster than governance workflows. This is the practical failure mode the article illustrates. The important lesson is that compliance evidence must survive real-world change, not only a point-in-time assessment. Practitioners should design for continuous assurance across the full payment-page lifecycle.
Lean compliance teams need automation to make browser controls sustainable. The article describes a small team managing multiple entities and a large page estate, which is typical of modern regulated enterprises. Manual oversight does not scale in that model, especially when the control objective is ongoing visibility rather than periodic inspection. Practitioners should prioritise controls that produce repeatable evidence with low operational overhead.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: SaaS-to-SaaS and OAuth App Governance Guide
What this signals
Client-side control is becoming a compliance boundary. As payment journeys shift into more dynamic browser environments, the question is no longer whether a page is protected at build time, but whether its runtime behaviour stays governed after every marketing or content change. Practitioners should expect audit evidence to depend increasingly on continuous monitoring rather than periodic review.
Third-party script governance now sits close to identity and access decisions. Who can introduce a tag, who approves it, and who can revoke it are governance questions that look increasingly familiar to IAM and PAM teams. The browser is now part of the broader control plane for customer data, so access discipline must extend to client-side execution paths.
92% of organisations expose NHIs to third parties, raising concerns about supply chain security. according to the Ultimate Guide to NHIs The wider lesson is that delegated execution and delegated access are converging risks, even when the asset is a browser page rather than a backend service.
For practitioners
- Inventory every web-based payment page Build and maintain a complete list of pages that accept card data, including pages added by marketing or business teams outside core IT.
- Govern third-party script approvals Require explicit review for every script or tag that can execute on payment pages, with a named business justification and security owner.
- Monitor browser-side integrity continuously Use runtime monitoring for headers and script behaviour so drift is detected after deployment, not only during periodic audits.
- Reduce manual compliance dependence Automate evidence collection and alerting so a small compliance team can support multiple entities without relying on ad hoc review.
Key takeaways
- Browser-side payment security now depends on controlling third-party execution, not just hardening the server-side stack.
- Dynamic web environments make point-in-time compliance fragile because approved scripts and pages can drift after deployment.
- Continuous monitoring and explicit ownership are the controls that turn payment-page integrity into an auditable governance process.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and PCI DSS v4.0 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Script approvals and runtime access to payment data mirror access governance concerns. |
| Recommendation — Apply PR.AA-05 to control which scripts can reach payment-page data and who can approve them. | ||
| CIS Controls v8 | CIS-5 — Account Management | Third-party browser actors need clear ownership, approval, and revocation discipline. |
| Recommendation — Use CIS-5 to keep ownership and revocation paths clear for every externally introduced script. | ||
| PCI DSS v4.0 | 6.4.3 — Client-side payment page script management | The article centres on meeting PCI DSS v4 browser-side script controls. |
| Recommendation — Implement browser-side script monitoring and approval evidence to satisfy PCI DSS v4 payment-page controls. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party scripts behave like externally introduced trusted components with supply chain risk. |
| NHI-10 — Human Use of NHI | Business teams can indirectly introduce machine-like execution paths outside security oversight. | |
| Recommendation — Inventory third-party execution paths and remove any script dependency that cannot be governed end to end. Prevent business teams from bypassing control review when adding scripts that can process sensitive data. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Browser-side script abuse can expose data and support exfiltration from trusted pages. |
| Recommendation — Map unsafe third-party script behaviour to TA0006 and TA0010 to prioritise detection on payment pages. | ||
Key terms
- Client-Side Integrity: Client-side integrity is the assurance that browser or app code has not been altered in ways that change security behaviour. In identity verification, it protects the trustworthiness of the capture, validation, and submission path before the server makes an authentication decision.
- Third-party script governance: Third-party script governance is the discipline of controlling which external scripts can run on a website and what data they can access. It combines provenance checks, policy enforcement, monitoring, and change control to prevent trusted integrations from becoming hidden theft paths.
- Payment-page drift: Payment-page drift is the gradual loss of control over a payment page as tags, scripts, and content changes accumulate outside the original security baseline. It is a governance problem because a page can remain live while its browser-side behaviour moves beyond what was reviewed.
- Browser-Level Monitoring: Browser-level monitoring observes user actions inside the web session rather than relying only on backend audit logs. It provides context for what a person viewed, copied, downloaded, or exported, which is especially useful when a SaaS platform does not expose enough detail for timely insider-risk investigation.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, and secrets management in the context of modern control design. It is a practical fit for practitioners who need to connect identity governance with wider security and compliance programmes.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org