PCI DSS v4.0.1 made the browser auditable. Since requirements 6.4.3 and 11.6.1 became mandatory on March 31, 2025, organizations assessed against them have had to inventory the scripts on their payment pages, justify and authorize each one, ensure their integrity, and detect unauthorized changes to those scripts and security-impacting HTTP headers.
That was overdue, and it gave security teams a forcing function they had lacked. But the requirements answer a deliberately narrow question: is this script on our payment page approved, and has it changed? Many of the attacks that matter most pass that test. They arrive through scripts that were approved, on pages that are out of scope, and they are often built to behave differently for real customers than for anyone checking.
Our view at Jscrambler is simple: authorization is not control. Knowing that a script is allowed on the page tells you nothing about what it is allowed to do once it runs: which fields it can read, which browser APIs it can call, and where it can send data. Closing that gap takes least-privilege enforcement inside live user sessions, across every page that handles sensitive data, not only checkout.
What is client-side security? Client-side security is the set of controls that govern how code behaves in the user’s browser: what first-party application logic and third-party scripts can access, change, and transmit while the page runs.
What PCI DSS v4.0.1 Asks Of The Browser, And What It Doesn’t
PCI DSS applies to the whole cardholder data environment. Its two client-side requirements are scoped to payment pages:
- Requirement 6.4.3 requires an inventory of all scripts on the payment page with a written justification for each, a method to confirm each script is authorized, and a method to assure each script’s integrity.
- Requirement 11.6.1 requires a change- and tamper-detection mechanism that alerts personnel to unauthorized modifications to the security-impacting HTTP headers and script contents of payment pages, as received by the consumer’s browser. It must run at least once every seven days, or at a frequency set by a targeted risk analysis.
11.6.1 is an alerting control, not a periodic audit. But its unit of analysis is still change: a new script, an altered script, a modified header. An approved script that hasn’t changed, yet reads more than it should, passes.
The SAQ A Change Didn’t Remove The Problem
In January 2025, the PCI Security Standards Council revised SAQ A, the self-assessment for e-commerce merchants that outsource payment to an embedded form or a redirect. It removed 6.4.3 and 11.6.1 (and the targeted risk analysis behind 11.6.1) from the questionnaire. In their place, merchants must confirm that their site “is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” The Council said the change affects how merchants report, not the underlying requirements.
FAQ 1588 (February 2025) explains how merchants that embed a payment form, such as an iframe, can make that confirmation: use techniques such as those in 6.4.3 and 11.6.1, or obtain confirmation from a PCI DSS-compliant service provider or payment processor that its embedded solution protects the page from script attacks when implemented as instructed. Either way, someone has to be able to show that the parent page can’t be used to attack the payment form. For payment service providers, Jscrambler Iframe Integrity provides the technical basis for that confirmation across their merchant base. More on the SAQ A changes.
The Structural Gap: Privilege Without Control
In your backend, you decide what code is deployed and what each service can access. In the browser, you don’t. Any script loaded into the page itself (the top-level document) runs with the same privileges as your own application logic. It can read form inputs as they are typed, register keystroke and submit listeners, read cookies that aren’t marked HttpOnly and anything in browser storage, rewrite the DOM, and wrap browser APIs such as fetch to see or change what the page sends.
The September 2025 compromise of the chalk and debug npm packages showed how little that takes. After a maintainer was phished, malicious versions of 18 packages with more than 2 billion combined weekly downloads were published. In the browser, the injected code hooked fetch, XMLHttpRequest, and wallet APIs, and rewrote cryptocurrency transaction recipients while the interface looked normal. The main exposure window lasted a couple of hours, which is long enough for any build that pulled a fresh install to ship the payload.
Cross-origin iframes are the exception. A payment form served from the provider’s origin in an iframe is isolated from the parent page’s scripts, and that isolation underpins the iframe checkout model PCI DSS relies on. But the parent page still controls where the iframe points and what is drawn on top of it. An attacker who can’t read the iframe can replace it, overlay it with a fake form, or inject a look-alike form before it loads.
Why Traditional Controls Miss Client-Side Risk
Each of these controls does its job. None govern what code does once it runs in the browser.
- Network controls and WAFs. Firewalls, network segmentation, and web application firewalls inspect traffic between the client and your servers. They are essential, and they never see the DOM. A skimmer that reads a form field and posts it from the browser straight to an attacker’s endpoint never crosses your edge.
- Build-time AppSec. SAST, software composition analysis, and SBOMs catch risky first-party code and dependencies before release. Most third-party code on a page arrives after deployment, through tags and vendor CDNs that update on their own schedule. A script reviewed in staging can be different in production hours later.
- CSP and SRI. Content Security Policy and Subresource Integrity are worth deploying, and they do more than they are often given credit for. SRI makes the browser refuse a pinned script whose content has changed. CSP restricts where scripts load from and, through connect-src, where the page can send data. Their limits are practical ones:
- SRI only works for scripts whose content is fixed. It can’t pin vendor scripts that change legitimately and often, or code that another script loads dynamically. Polyfill.io served a different bundle depending on the visitor’s browser, so it couldn’t be pinned, and it was compromised in 2024.
- CSP allowlists are coarse. They approve a domain, not a behavior. Attackers exfiltrate through domains you have already allowed, such as analytics and tag manager endpoints, and CSP can’t stop an allowed script from reading a field it has no business reading.
- Tag governance. Marketing, growth, and product teams add tags through tag managers, often outside AppSec review. These shadow scripts, and the fourth-party scripts they load in turn (code your vendors pull in from their own suppliers, which you have no contract with), change faster than static allowlists can follow.
PCI DSS Client-Side Requirements vs. Full Client-Side Security
| Dimension | PCI DSS v4.0.1 (6.4.3 and 11.6.1) | Full client-side security |
|---|---|---|
| Scope | Payment pages. (The rest of PCI DSS covers the whole cardholder data environment.) | Every page that handles sensitive data: login, account, registration, password reset, health and financial forms, and checkout |
| Question answered | Is each script authorized, justified, and unchanged? | What is each script allowed to access and transmit while it runs? |
| Control model | Alerts on unauthorized changes to scripts and security-impacting HTTP headers, at least weekly or at a frequency set by targeted risk analysis | Least-privilege enforcement in live user sessions: field-level access, browser API exposure and permitted destinations, with blocking |
| Data in scope | Cardholder data | Cardholder data, credentials, PII, PHI, financial data, behavioral signals and first-party application logic |
| Evidence | Script inventory, justifications and change alerts for assessors | The same, plus records of access attempts, blocked behaviors and data flows, reusable across PCI DSS, privacy and AI governance |
Four Areas Where Control Has To Extend
These aren’t four products bolted together. They are one principle, least privilege enforced at runtime, applied to the four kinds of code and data that meet in the browser. In the Jscrambler Client-Side Security Platform, the Behavioral Enforcement Core applies that principle across all four.
1. Third-party scripts and the browser supply chain
The question to answer isn’t “which scripts are on the page?” but “what can each one touch?” Field-level policy lets an analytics tag record page views on checkout without reading the card number, and lets a chat widget run on the account page without reading the password field. Script-level allow-or-block forces a choice between breaking functionality and accepting risk.
That enforcement has to happen in real user sessions, because modern skimmers are conditional. When Sansec disclosed the Polyfill.io compromise in June 2024, affecting more than 100,000 sites, the payload activated only on specific mobile devices, ran only at certain hours, stayed dormant when it detected an administrator, and delayed execution when web analytics were present. A Magecart campaign reported in January 2026, targeting customers of six major card networks, can remove itself from the page when it detects an admin session. A crawler loading your page from a data center, or a staff member testing checkout, may never see the malicious version. A control that runs in each customer’s session can.
The Jscrambler Webpage Integrity product continuously discovers third- and fourth-party scripts, maps which of them access login fields, payment fields, cookies, browser storage, and forms, detects behavioral drift, and blocks specific unauthorized reads or transmissions without breaking the page.
2. Privacy and data governance
Privacy exposure from client-side code is concrete, and regulators are acting on it. Three patterns keep recurring:
- Trackers that ignore the user’s choice. In July 2025, California’s Attorney General secured $1.55 million from Healthline.com, then the largest CCPA settlement, after finding that the site kept sharing data with advertising partners after consumers opted out, and that its consent banner didn’t disable tracking cookies.
- Cookies set before consent or after refusal. In September 2025, France’s CNIL fined Shein €150 million, finding among other things that advertising cookies were placed without consent and kept being set or read after users refused.
- Opt-out signals that never reach the tags. In February 2026, the California Privacy Protection Agency fined ticketing platform PlayOn Sports $1.1 million, including for not honoring Global Privacy Control signals and for offering opt-out channels that couldn’t change website tracking.
Add the steady flow of US wiretap and pixel class actions, many brought under state laws such as California’s Invasion of Privacy Act, and the lesson is consistent: what counts is what tags actually do, not what the banner promises.
The legal hooks differ by regime. In the EU and UK, consent for cookies and similar trackers comes from the ePrivacy rules (PECR in the UK), while GDPR governs the processing that follows. CCPA/CPRA is mainly an opt-out regime, including an obligation to honor opt-out preference signals. In US healthcare, HHS OCR guidance treats tracking on regulated entities’ sites as a HIPAA matter, although a federal court vacated part of that guidance covering certain unauthenticated public pages in June 2024. Tracking on authenticated pages such as patient portals remains squarely in scope.
Jscrambler’s own research, Beyond the Vault: What Banking Sites Quietly Share Before You Ever Log In, found the same gap in financial services: banking sites in Europe and the US routinely send sensitive customer data to advertising and analytics platforms, often before a consent choice and sometimes after tracking was rejected.
Consent management platforms do their job: they capture and record the user’s choice. Enforcing that choice in the browser is a separate control. Webpage Integrity ties script policy to consent state, so tags can’t read or send data the user hasn’t agreed to share.
3. AI components on the page
Assistants, chatbots, and personalization engines are now common third-party tags, and the risk is specific. Consider a support assistant that, to give context-aware answers, collects the visible page content and the user’s recent inputs into its prompt. On an account or checkout page, that can include form fields such as card details, an ID number, or a symptom typed into a booking form, all sent to the vendor’s model without anyone deciding they should be.
Two objections deserve a straight answer. Many assistants do render their chat window in an iframe, but the loader script that injects it usually runs in your page, with full access to the DOM. And vendors do offer retention limits and zero-retention agreements, but those govern what happens after data leaves your page. They don’t decide what leaves. You can enforce that decision only in the browser, before the prompt is assembled.
The same field-level policies apply: you can allow an AI component to read product content while denying payment, credential, and health fields. That lets teams adopt AI features without widening their data exposure.
4. Integrity of your own application logic
The first three areas are about third parties reaching your users’ data. This one is about attackers working on your code, and it is what holds the model together: every control described above also runs in the browser. Your checkout validation, your fraud and bot signals, your consent handling, and the enforcement layer itself are all delivered to a device you don’t control, where anyone can read, debug, and modify them.
The standard objection is that security through obscurity doesn’t work and that secrets don’t belong in client-side code. Both points are right. The goal isn’t to hide secrets. It is about integrity and attacker cost: making sure the logic that runs is the logic you shipped, that it refuses to run when tampered with or outside approved environments, and that analyzing it costs more than it is worth. If attackers can strip out your fraud signals or rewrite a price check, your backend receives inputs that look valid.
LLMs have made that analysis cheaper. They can map minified or lightly obfuscated code quickly, because its control flow stays intact. The Jscrambler Code Integrity product combines polymorphic obfuscation, so each protected build differs from the last, with control-flow flattening, VM-based obfuscation, and self-defending and anti-tampering runtime checks. That is what LLM-Resilient Code Protection means: analysis doesn’t become impossible, but it stops being cheap and easy.
The Obvious Objection: Isn’t The Agent Just Another Third-Party Script?
Runtime enforcement means running code on the page, so a skeptical reader should ask whether it simply adds one more privileged script. It’s the right question, and you should ask it of any vendor in this category. A credible answer has two parts.
- The agent has to defend itself. An enforcement layer that the scripts it governs can disable or patch is worthless. Jscrambler hardens its Webpage Integrity agent with the same self-defending protections Code Integrity applies to customer code, so it detects and blocks attempts to tamper with or bypass it.
- It has to earn its place on the page. Policies can be tested in a staging environment before enforcement, and deployment can be agentless on lower-risk pages and agent-based where sensitive data is handled.
Making The Case Beyond The Mandate
PCI DSS sets a floor for payment pages. The case for going further rests on four points:
- Breach cost. IBM’s 2026 Cost of a Data Breach Report puts the global average cost of a breach at $4.99 million, and $11.5 million in the US. Supply chain compromise was the second most common initial attack vector.
- Reach. A single compromised dependency like Polyfill.io reached more than 100,000 sites at once.
- Regulatory exposure. The privacy actions above, ranging from $1.1 million to €150 million, all turned on tags and trackers behaving differently from what users were told. That behavior happens in the browser, where runtime enforcement operates.
- One control plane, several mandates. The same inventory, policies, and evidence support PCI DSS, GDPR and ePrivacy, CCPA/CPRA, CIPA, HIPAA, and AI governance programs, instead of separate tooling and separate audits for each.
Where To Start
- Extend your PCI DSS controls beyond checkout. The inventory, authorization, and change detection you built for 6.4.3 and 11.6.1 are the foundation. Extend them to login, account management, registration and password reset, and to any form that collects health, financial or identity data.
- Transition from scanners to agent-based runtime enforcement. While agentless scanners help establish quick compliance, hybrid or agent-based solutions provide real-time continuous behavioral analysis and automated blocking capabilities needed for true risk reduction.
- Give every third-party tag an owner and a data budget. Keep a script register that records, for each tag, the business owner, its purpose, the pages it may run on, the data fields it may access, the destinations it may send data to, and a review date. Route new tags from marketing and product through a lightweight approval in which security sets the data policy, not just yes or no. Treat behavioral drift as a trigger for re-review. This turns a PCI DSS justification spreadsheet into governance that security, privacy, and marketing can all work from.
Conclusion
PCI DSS v4.0.1 established that the browser is part of your security boundary. It asks you to know which scripts are on your payment pages and to notice when they change. That is necessary, and it isn’t sufficient: the incidents and enforcement actions of the past two years came through approved scripts, on pages outside PCI DSS scope, and through tags that did more than users agreed to.
Client-side security closes that gap by enforcing what each piece of code can access and transmit in live sessions, and by protecting the logic that enforces it. Visibility tells you what happened. Client-Side Security governs what is allowed to happen.
To see how to extend your PCI DSS controls across the rest of your web estate, visit Jscrambler’s Why Client-Side Security page.
