Browser-side data governance and PCI control gaps in web apps

At a glance

What this is: This case study shows how a large enterprise used browser-side controls to manage third-party script risk and meet PCI DSS client-side requirements.

Why it matters: It matters to IAM and security practitioners because browser-side access to sensitive data is another authorisation boundary, especially when third-party code can observe or exfiltrate information.

👉 Read Jscrambler's case study on browser-side PCI control and script integrity

Context

Browser-side governance is often treated as a web or compliance problem, but it is really an access-control problem at the edge of the application. When third-party scripts, tags, and widgets can observe form fields, browser storage, or page content, they create a control gap that traditional server-side security does not see. In this case, the primary browser-side security issue is how to preserve visibility and policy enforcement while still supporting marketing, analytics, and payment flows.

That gap matters to IAM and NHI practitioners because client-side code is increasingly part of the access path to sensitive data, even when no human user is directly involved. The same governance logic used for NHI, secrets, and privileged access applies here: know what is running, what it can access, and when it should be blocked. The starting position described here is typical for large, digitally complex enterprises, not an outlier.

For PCI and privacy programmes, the browser has become a policy enforcement point where third-party trust must be continually re-validated. That makes client-side inventory, script approval, and data fencing part of the broader identity governance conversation, especially where external code behaves like an unmanaged non-human actor.

Key questions

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. Third-party code can read form fields, alter page behaviour, or redirect data paths, and teams lose the ability to prove what touched payment information. The failure is not just technical exposure. It is a breakdown in ownership, approval, and revocation for client-side access.

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: 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. If any of those answers require manual reconstruction, governance exists on paper but not in operations.

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.

Technical breakdown

Why client-side script integrity becomes an authorisation problem

Modern websites rarely load only first-party code. They rely on analytics, advertising, tag management, chat, and payment libraries that execute inside the browser with access to the same page context as the user. That means a third-party script can read fields, observe events, and influence the document object model unless the organisation enforces policy at runtime. Integrity controls such as content checks, allowlisting, and monitoring turn the browser into a governed execution environment rather than a blind trust zone.

Practical implication: Treat browser-executing scripts as controlled actors and define which code may access sensitive page elements.

How form fencing and runtime monitoring work together

Form fencing blocks unauthorised script access to specific fields, while runtime monitoring watches for unexpected data access, header tampering, or new script behaviour. Together, they separate detection from prevention. Prevention limits what a script can touch, and monitoring gives visibility into attempted abuse or policy drift. That combination is useful in dynamic environments where page content changes often and manual reviews cannot keep up.

Practical implication: Use preventive field-level controls on payment and login pages, then route exceptions and alerts into a security workflow.

Why PCI DSS v4 pushes client-side governance earlier in the lifecycle

PCI DSS v4.0 introduced explicit attention to script integrity on payment pages because skimming can happen entirely in the browser before data ever reaches back-end controls. The important shift is that compliance is no longer only about securing servers and networks. It now includes proving that page scripts are inventoried, authorised, and monitored, with evidence that suspicious changes are detected and handled.

Practical implication: Map client-side controls to payment-page evidence requirements and keep an auditable inventory of scripts and approvals.

Threat narrative

Attacker objective: The attacker wants to capture payment and identity data from the browser while avoiding detection by back-end controls.

1. Entry occurs when an attacker compromises a third-party script, tag, or analytics library embedded in the page.
2. Escalation happens when that script inherits the browser context and can access form inputs, storage, or page events beyond its original business purpose.
3. Impact follows when sensitive customer data is skimmed or exfiltrated without affecting the visible user experience, making the breach hard to detect.

Breaches seen in the wild

• JetBrains Marketplace AI Plugin Campaign — 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.
• Code Formatting Tools Credential Leaks — Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Shadow client-side code is the browser analogue of shadow NHI. Marketing tags, embedded widgets, and vendor scripts can appear without central security oversight, then persist long after their business justification fades. This is a named governance gap because the control failure is not lack of tools alone, but lack of ownership over what code is allowed to act inside the browser. The conclusion for teams is to enforce explicit ownership and review for every script with data access.

Client-side compliance succeeds when policy is enforced at runtime, not after the fact. Static review cannot keep pace with pages that change frequently and with code that can alter its behaviour after deployment. That is why browser integrity, field fencing, and alerting matter together. The practitioner conclusion is to move from periodic assurance to continuous enforcement on high-risk pages.

PCI DSS v4.0 is accelerating a broader shift from environment trust to evidence-based control. The standard’s attention to script integrity reflects a market reality: sensitive data is increasingly exposed before it reaches traditional security boundaries. That makes runtime evidence, not assumption, the basis for governance. The practitioner conclusion is to align payment-page controls with continuous verification rather than one-time compliance checks.

From our research:

• 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.
• Client-side trust gaps widen when third-party code is allowed to act without continuous authorisation, which is why Top 10 NHI Issues is relevant to browser governance as well.

What this signals

Shadow client-side execution is becoming a governance blind spot. As more business logic moves into the browser, security teams need to treat scripts, tags, and widgets as governed actors rather than invisible dependencies. The practical signal is that page-level inventory and runtime policy enforcement should be folded into NIST Cybersecurity Framework 2.0 style control thinking, not left to ad hoc web teams.

Browser-side data access creates an identity-style trust problem even when no formal identity exists. Third-party code can behave like an unmanaged non-human actor with access to sensitive fields, and that means governance must focus on authorisation, scope, and revocation. Teams that already manage NHI risk can apply the same discipline to client-side controls, especially where script inventory and approval workflows are weak.

The pressure from PCI DSS and related privacy expectations suggests that client-side evidence will matter more in audits and incident reviews. Practitioners should expect greater demand for runtime telemetry, ownership records, and demonstrable field-level controls, especially on pages where customer and payment data intersect.

For practitioners

• 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. Include ownership, purpose, and the specific fields each script can touch so security and compliance teams can review actual exposure rather than page-level assumptions.
• 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. Use exceptions only when a business owner can justify the data path and security has approved the scope.
• 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. That gives compliance and SOC teams one place to review evidence and escalation.
• Tie approvals to page ownership Assign explicit business and technical owners to each page that processes sensitive data, then require re-approval when scripts, tags, or payment flows change. This prevents unmanaged drift in environments where marketing or sales can alter pages outside IT.

Key takeaways

• Browser-side security is an access-control problem as much as a web integrity problem.
• Third-party scripts can create unmanaged data access paths that traditional back-end controls do not see.
• Continuous inventory, field fencing, and runtime monitoring are the controls that turn client-side trust into evidence-based governance.

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.
• Form fencing: A browser security control that limits which scripts can read, modify, or transmit data from specific form fields. It reduces exposure of cardholder data and personal information by constraining runtime access at the point where sensitive data is entered.
• Script Inventory: Script inventory is the process of identifying, classifying, and maintaining ownership records for all code loaded into a web page. In security terms, it establishes what code is present, who added it, what it can access, and whether its presence is still justified.
• Shadow Client-Side Code: Shadow client-side code refers to browser scripts, tags, and widgets that have been introduced without clear security oversight or lifecycle governance. These components can persist unnoticed, creating hidden access paths to sensitive data and making web governance resemble unmanaged identity sprawl.

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

👉 The full Jscrambler case study covers page inventory, deployment choices, and compliance evidence in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is suitable for practitioners building governance across human, non-human, and agentic identity programmes.