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.
At a glance
What this is: This is a case study on browser-side data governance, showing that dynamic web apps can make PCI control coverage and client-side visibility difficult even when teams already know the relevant requirements.
Why it matters: It matters because IAM, application security, and compliance teams increasingly need control over what runs in the browser, what data it can touch, and how third-party scripts are governed.
By the numbers:
- Marriott Vacations Worldwide protected 160 card data flows across six distinct entities.
Context
Browser-side data governance is the discipline of controlling what scripts, tags, and embedded services can access inside the user’s browser. In modern web applications, that control problem sits at the intersection of application security, privacy, and compliance because the browser has become a high-trust execution environment for third-party code.
This article shows why PCI DSS requirements 6.4.3 and 11.6.1 are difficult to satisfy in large, dynamic web estates: page inventories are incomplete, marketing teams change site code outside central IT, and third-party scripts expand the attack surface faster than manual review can keep up. The identity angle is indirect but real, because browser-side controls increasingly govern access to payment data and other user information.
For organisations with multiple brands, entities, or payment journeys, the starting position described here is typical rather than exceptional: the problem is not one unsafe page but many lightly governed client-side dependencies spread across a changing estate.
Key questions
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. Limit their field access, inventory every dependency that executes in the checkout flow, and require approval for changes that affect sensitive inputs. The goal is to reduce browser-side data exposure before payment data or identity data can leave the page.
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. PCI and privacy programmes need evidence that scripts are inventoried, approved, and constrained at runtime, otherwise the organisation is relying on assumptions about page behaviour that can change without notice.
Q: What breaks when client-side script inventories are incomplete?
A: Incomplete inventories leave teams unable to prove which pages collect card data, which scripts can access it, and where unauthorized changes entered the browser. That makes compliance evidence weak and incident response slower because security teams cannot quickly isolate the affected page, tag, or business owner.
Q: How should organisations balance marketing tracking with browser security controls?
A: Allow only the trackers that have a clear business purpose, a defined data scope and a documented owner. Then enforce runtime boundaries so analytics tools cannot read more data than the policy allows, even when they are technically approved.
Technical breakdown
Why third-party scripts are a governance boundary
Third-party scripts are not just external dependencies. In the browser, they execute with access to the same page context as first-party code, which means a benign analytics tag can become a data-access path if it is modified, misconfigured, or abused. That creates a governance boundary inside the client session itself, where control must focus on what each script can observe or touch, not merely whether it loads. In PCI-sensitive environments, this is why script provenance, page scope, and runtime behavior matter together.
Practical implication: Map browser scripts to specific data-access permissions instead of treating all injected code as equally trusted.
How PCI DSS 6.4.3 and 11.6.1 change client-side control
PCI DSS 6.4.3 and 11.6.1 push teams toward continuous script integrity and change detection on payment pages. That changes the control model from periodic review to monitored enforcement, because payment pages are dynamic and can change outside the compliance team’s direct view. The practical challenge is not only finding authorized scripts, but also detecting when approved pages, tags, or headers change in ways that alter the payment-page trust boundary. This is a browser governance problem, not just a checkbox exercise.
Practical implication: Treat PCI evidence as a live control stream tied to page changes, script integrity, and monitored payment-page scope.
Why manual review fails in large web estates
Manual script oversight breaks down when site refreshes, marketing edits, and multiple codebases create a moving target. The article’s example shows that even finding every card-accepting page can take months, which means governance based on periodic audits will always lag behind the actual client-side environment. The bigger issue is drift: approved business changes can quietly widen access to sensitive data before compliance or security teams even notice. That is why browser-side monitoring and policy enforcement need to operate continuously.
Practical implication: Replace periodic script reviews with continuous monitoring that detects drift as pages and tags change.
Threat narrative
Attacker objective: The attacker aims to harvest payment or personal data from the browser while remaining invisible to normal site users and many backend controls.
- Entry occurs through third-party scripts, marketing tags, or compromised browser-side libraries that run inside the payment page context.
- Credential or data access happens when the injected script can read form fields, cookies, or browser storage without sufficient restriction.
- Impact follows when sensitive payment or identity data is exposed, skimming occurs, or browser-side integrity controls fail to detect the change.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
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 governance is now a data-access control problem, not a front-end hygiene issue. When third-party tags and dynamic scripts can touch payment fields, the browser becomes a governed execution surface. That means security teams have to think in terms of who can access which data in the client session, not just which code is deployed. The practitioner conclusion is straightforward: browser governance belongs in the security control model, not only in web operations.
PCI compliance alone does not solve client-side trust drift. Requirements such as 6.4.3 and 11.6.1 help frame the problem, but they do not remove the operational reality of marketing-led changes, multiple codebases, and long-lived page inventories. The compliance issue is therefore a visibility and accountability gap as much as a technical one. Teams need controls that stay aligned with how web content actually changes.
Client-side script inventory is the named concept that matters here. If you cannot reliably inventory every payment page, tag, and browser dependency, you cannot govern the access path those components create. The article shows that the discovery problem can take months even in mature organisations, which makes stale inventories a structural risk. The practitioner conclusion is to treat inventory completeness as a prerequisite for any meaningful browser-side governance.
Lean compliance teams need runtime enforcement because review queues cannot keep up with page churn. The article shows that manual approvals and periodic checks become fragile once business teams can alter pages independently. Runtime blocking, integrity monitoring, and scoped approvals reduce the gap between approved state and actual state. The practitioner conclusion is that governance must move closer to execution time.
This pattern is a warning for broader identity governance programmes. Browser-side access to data is another example of a trust boundary that exists at runtime, not just in policy documents. For organisations already struggling with NHI, SaaS-to-SaaS, and delegated access governance, the browser is part of the same problem space: granted access must be observable where it is exercised. The practitioner conclusion is to align application, identity, and privacy governance around live access paths.
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 governance is becoming a control-plane problem for web applications. The browser now hosts business logic, tags, and third-party integrations that can touch sensitive data before any backend check is useful. That shifts risk management toward runtime enforcement, scoped approvals, and continuous inventory, because static review cannot keep pace with site churn.
Browser-side access should be treated like any other privileged data path. When a script can read form fields, cookies, or storage, it has an effective access entitlement whether or not the application team intended one. Practitioners should therefore align web security, privacy, and compliance controls around observed runtime behavior, not only around declared architecture.
For practitioners
- Inventory every browser-exposed payment page Build a complete register of pages that can accept card data or expose sensitive personal data, then keep that register current as business teams change site content and code.
- Classify third-party scripts by data access Group tags, analytics libraries, and embedded services by the form fields, cookies, or storage they can reach so approvals reflect actual browser-side risk.
- Enforce runtime controls on sensitive pages Use browser-side enforcement to block unauthorized script access to payment forms while allowing approved business functions to continue operating.
- Tie compliance evidence to page-change monitoring Capture script integrity and header integrity evidence continuously so PCI control checks reflect live changes rather than a one-time assessment.
- Set escalation rules for marketing-led changes Require security review when non-IT teams introduce or modify scripts on pages that collect payment or identity data, especially where third-party vendors are involved.
Key takeaways
- Browser-side governance is now part of the control model for payment and privacy data, because third-party scripts can widen access inside the page itself.
- The article shows that discovering every payment page and maintaining visibility across a large web estate can take far longer than many teams expect.
- Continuous monitoring and runtime restriction are the control moves that matter when site changes, tags, and compliance requirements evolve together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security 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 |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article centers on browser-side policy gaps and unsafe page-level exposure. |
| Recommendation — Harden browser-facing controls to prevent misconfiguration from exposing sensitive data paths. | ||
| NIST CSF 2.0 | PR.DS-10 — Confidentiality, Integrity and Availability are Protected | Client-side integrity and data protection are the main governance concerns here. |
| Recommendation — Apply PR.DS-10 to protect payment-page integrity and limit browser-side data exposure. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article’s governance problem includes third-party access and scoped approvals. |
| Recommendation — Use CIS-5 to control who can approve and alter scripts that access sensitive page data. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The threat pattern is browser-side harvesting and data removal through injected code. |
| Recommendation — Map client-side skimming and data theft behaviours to TA0006 and TA0010 in detection workflows. | ||
| PCI DSS v4.0 | 6.4.3 — Script Integrity | PCI DSS 6.4.3 is one of the article’s explicit compliance anchors for payment pages. |
| Recommendation — Use 6.4.3 controls to validate and monitor scripts that run on payment pages. | ||
Key terms
- Browser-side Data Governance: The practice of controlling which scripts, tags, and embedded services can access sensitive data inside a web browser. It focuses on runtime behavior, page scope, and trust boundaries in the client session, where data can be exposed before server-side controls see anything.
- 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 Scope: The set of web pages, forms, and browser elements that can collect or expose cardholder data. In PCI programmes, scope is not only a technical inventory but a governance boundary that determines which pages need continuous monitoring and stronger control.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for practitioners who need to connect identity governance to access control, secrets, and runtime risk.
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