by Source Defense
PCI DSS 4.0.1 represents a meaningful evolution in payment security, acknowledging that client-side threats are now part of the risk landscape. Requirements such as script inventory, change detection, and tamper monitoring reflect growing awareness of eSkimming and supply chain attacks.
However, while the intent is right, the standards still fall short of addressing how modern attacks actually work. The gap lies not in what PCI requires, but in what it assumes.
A Myopic Scope Limited to Payment Pages
PCI DSS 4.0.1 assumes that attackers need access to payment pages in order to steal card data…they do NOT. Compromised scripts anywhere within a website can be used to add form fields, replace legitimate forms, redirect users to domains under the attacker’s control, etc. As a result, focusing only on payment page security overlooks the fundamental nature of how these javascript based attacks work. While the DSS makes tremendous strides in addressing eSkimming, it fails to recognize the attack surface as the website itself, not specific pages.
Point-in-Time Controls in a Runtime World
PCI DSS 4.0.1 emphasizes visibility—knowing which scripts are present and detecting changes. These are important steps, but visibility alone does not equal protection.
Modern eSkimming attacks frequently involve:
- Malicious behavior introduced without obvious file changes
- Conditional execution based on user attributes
- Abuse of legitimate scripts rather than injection of new ones
- Data exfiltration through approved endpoints
In these scenarios, scripts may remain unchanged while their behavior shifts dramatically. A change-detection model cannot reliably identify this risk.
Inventory Is Necessary but Not Sufficient
Knowing which scripts exist does not reveal what they do. A compliant inventory may list all third-party resources accurately, yet still fail to capture unauthorized data access or exfiltration occurring at runtime.
PCI requirements implicitly assume that once scripts are inventoried and monitored for change, risk is reduced. In reality, attackers have adapted specifically to evade this model.
Referencing Outdated Controls for a Modern Attack Surface
The DSS in its current form calls out both Content Security Policy (CSP) and Subresource Integrity (SRI) as example controls for eSkimming. They fail and should not be referenced as they provide incorrect guidance to merchants. These approaches were introduced with the right intentions: to limit unauthorized resource loading and to ensure that scripts cannot be tampered with undetected. In theory, CSP and SRI should provide strong protections against client-side threats like eSkimming. In practice, however, they fall short and often dramatically so.
The modern web simply evolved faster than these standards were designed to handle. The dynamic, script-heavy, API-driven architectures of today’s websites are fundamentally incompatible with rigid policy-based controls.
Where the Standards Need to Evolve
To truly address modern eSkimming, future iterations of PCI should move beyond passive monitoring and toward active enforcement. That evolution could include:
- A site wide focus on script security – not just a payment page focus
- The elimination of CSP and SRI as reference approaches
- Runtime behavioral monitoring of scripts
- Controls that prevent unauthorized access to payment data
- Policies that restrict script interaction with sensitive DOM elements
- Enforcement mechanisms, not just detection requirements
These changes would align PCI more closely with how client-side threats actually manifest.
The Compliance Illusion
One of the unintended consequences of the current standard is a false sense of security. Organizations may believe they are protected because they meet the requirements, even while attackers operate undetected through trusted scripts.
PCI compliance should represent a baseline, not a ceiling. Without behavioral enforcement, organizations remain exposed – even when audits are passed.
The industry has taken an important first step by acknowledging client-side risk. The next step must be ensuring that standards reflect the realities of browser-based attacks, not just their existence.
PCI DSS 4.0 makes client-side security a priority.
Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.