PCI DSS 4.0.1: When eSkimming Compliance Creates a False Sense of Security

by Source Defense

PCI DSS 4.0.1 was supposed to close the gap on eSkimming. The extended deadline for the new eSkimming controls came and went on April 1, 2025, yet most merchants are still exposed and many are already hearing from their QSAs that they are failing the new requirements.

The uncomfortable reality: you can technically “tick the box” on 6.4.3 and 11.6.1 and still be wide open to eSkimming attacks. In some cases, the way organizations are interpreting PCI DSS 4.0.1 actually creates a false sense of security that works in the attacker’s favor.

Here we will unpack why that is happening and what a more realistic eSkimming strategy should look like.

The eSkimming Problem PCI DSS 4.0.1 Is Trying To Fix

Modern websites are built from other people’s code. Roughly 80 percent of the JavaScript running in a typical ecommerce session comes from third and nth parties, not from your own development team.

That code powers everything from analytics and personalization to chat, ads and payment flows. It also has direct access to sensitive data at the point of input. When attackers compromise one of those vendors, they do not need to break into your network. They simply ride in on legitimate scripts and quietly harvest:

• Payment card data
• Credentials
• Personal and health information

Card brands and investigators have been warning for years that this is now a primary source of fraud in card-not-present environments. Visa has repeatedly called out ecommerce platforms and third-party integrations as one of the most common attack paths for payment data and PII.

eSkimming is not theoretical. It is the tactics, techniques and procedures behind Magecart, formjacking, digital skimming, credential harvesting and a long list of high profile breaches.

PCI DSS 4.0.1 introduced two specific requirements to address this:

• 6.4.3: Manage and control scripts on payment pages
• 11.6.1: Detect and alert on unauthorized changes to those pages

On paper, that is a big step forward. In practice, there are some serious gaps.

What 6.4.3 And 11.6.1 Actually Require

At a high level, PCI DSS 4.0.1 expects organizations to:

For 6.4.3 (Script Management):

• Maintain an inventory of all scripts running on payment pages
• Confirm that each script is authorized by the organization
• Justify why each script is necessary
• Assure the integrity of each script, so you can tell if it has been modified

For 11.6.1 (Change Detection):

• Monitor payment pages and relevant HTTP headers for changes at least once every 7 days
• Alert teams to suspicious or malicious changes
• Respond to those alerts in a timely way

If you are just now getting pressure from your QSA on these items, you are not alone. Many merchants are still being told for the first time that they are failing these controls and need to implement something quickly.

The problem is not the intent of these requirements. The problem is how they are being implemented and what the examples in the standard encourage organizations to do.

Static Controls, Dynamic Attackers

Throughout the DSS, the council cites Content Security Policy (CSP) and Subresource Integrity (SRI) as example ways to meet the new eSkimming requirements.

That has led many teams down a difficult path.

CSP is essentially a whitelist that tells the browser which domains it is allowed to load resources from. In a typical implementation:

• You decide which third party services and origins to trust
• You store that policy on your servers
• Browsers enforce the policy and block anything that is not on the list

The problem is that attackers are not usually spinning up brand new malicious domains. They are compromising the exact third parties you are already allowing and abusing that trust. Once an approved analytics, chat or ad provider is compromised, your CSP policy is effectively saying “please let this malicious code run in every customer session.”

SRI has a different flaw. It relies on static hashes of script content. If the hash matches, the script runs. If it does not match, the browser blocks it. That sounds good in theory, but it does not align with how modern JavaScript actually behaves:

• Scripts are highly dynamic and change frequently
• Large sites may see thousands of script changes per month
• Keeping hashes in sync becomes almost impossible at scale

One large multinational merchant reported seeing roughly 11,000 script changes in a month when they tried this approach. They could not keep up and abandoned the strategy. On top of that, SRI fails quietly. When something breaks, you may not get clear reporting, which is a poor fit for a control that is supposed to support 11.6.1 change detection and alerting. These are static controls in a very dynamic environment. They create operational drag, break functionality and still do not understand or control what scripts actually do in the browser.

That is exactly why an 80 person PCI task force on ecommerce security explicitly warned the council that there was too much reliance on CSP in the DSS and pushed for stronger guidance on its shortcomings. Independent reviews, including work by VikingCloud and others, have since reinforced the benefits of behavior based approaches over static policy controls.

The Blind Spot: Focusing Only On Payment Pages

Another structural problem is scope. The standard pushes organizations to focus their new controls on the payment page. That seems intuitive. It is also misaligned with how attacks actually work. Joint research with Verizon looked at 7,000 of the world’s largest websites and identified 130,000 distinct scripts. Of those,

• 78,000 were running across the wider site, not just on payment pages
• 50,000 were present in payment flows
• Roughly 17,000 were doing risky things like accessing PII, credentials or payment data

Forensic investigators see the same pattern in real incidents. SecurityMetrics reported that in more than 2,000 eSkimming investigations, 100 percent of attacks originated on the referring page or the rest of the site, not on the payment page itself.

Once an attacker owns a script anywhere on your site, they can:

• Change page content and swap your legitimate checkout button for one that sends customers to an attacker controlled site
• Inject extra fields upstream of checkout and steal card data while a user is only logging in or joining a loyalty program
• Record keystrokes and harvest credentials long before payment

By the time the browser reaches the official payment page, the damage is already done. Focusing controls on that last step of the journey is a governance problem, not a security solution. If you want to stop eSkimming, you have to think in terms of site wide controls, not just the final form where card numbers appear.

SAQ-A And The Compliance Shell Game

The confusion around SAQ-A has made matters worse, especially for smaller merchants and some very large ones. In an attempt to simplify life for “mom and pop” shops, the council modified SAQ-A and removed explicit requirements for 6.4.3 and 11.6.1 for eligible merchants. At the same time, they changed the eligibility criteria so that those merchants must now attest that their ecommerce sites are not susceptible to script based attacks.

There are two big problems with that:

1. Many Level 1 merchants use SAQ-A. It was never just a small merchant tool, so the change accidentally created a loophole for some of the richest targets in the ecosystem.
2. The logic is circular. How can a merchant credibly claim their site is not susceptible to script attacks if they do not have meaningful controls in place to detect or prevent them in the first place?

The council later tried to clarify the situation in FAQ 1588. That document effectively tells SAQ-A merchants to either implement techniques similar to 6.4.3 and 11.6.1 anyway, or rely on a PCI compliant third party service provider or processor that can attest to protecting the payment page from script attacks.

For many organizations, this has turned into a compliance shell game instead of a serious security program. The risk does not go away just because responsibility is pushed across a contractual boundary. Attackers will happily exploit the weakest link in the chain, whether that is the merchant, the PSP, or an ecommerce platform partner.

Detection Only Strategies Are Not Enough

One more architectural issue: PCI DSS 4.0.1 is satisfied if you can detect malicious changes and respond. It does not require you to automatically block those behaviors in the browser. That is a risky posture in a world where:

• SOC teams are already overwhelmed with alerts
• Attackers are using slow, low, stealthy data exfiltration tactics
• eSkimming scripts can hide inside legitimate services like Google Analytics and persist for months or years

Security teams know how this story goes. In the Target breach, FireEye generated alerts, but the volume and context made it hard for the SOC to act in time, and a historic compromise followed despite having “detect and respond” tools in place.

The same pattern is likely if your eSkimming strategy is based solely on scanning, header checks and manual response. You might technically meet 11.6.1, but you are still relying on humans to outrun an automated, browser based attack that is designed to stay below the radar.

A more sustainable model is prevention first: enforce behavior based controls on scripts in real time, inside the browser, and block anything that tries to access or exfiltrate data in ways it should not. Detection and response still matter, but they should be a backup, not the front line.

What Good eSkimming Security Looks Like In Practice

If you strip away the noise, strong eSkimming security has a few clear characteristics:

1. Site Wide Coverage
   Controls apply across the full site, not only on checkout or payment pages. This is the only realistic way to address attacks that begin on upstream pages or via third party services embedded throughout the digital experience.
   
2. Behavior Based, Not Domain Based
   The system understands and governs what scripts do in the browser, not just where they are loaded from. It can:
   • Isolate risky scripts
   • Redact sensitive data such as keystrokes
   • Block unauthorized reads, writes and exfiltration attempts in real time
     
3. Prevention With Evidence For PCI DSS 4.0.1
   The same platform that blocks malicious behavior should also help you:
   • Automatically build and maintain a script inventory
   • Record authorizations and justifications
   • Continuously monitor for changes and provide audit ready reporting
     
4. Low Operational Overhead
   Controls should be easy to deploy, typically via a small code insert, and take hours per month to operate, not a dedicated team.
   
5. Aligned With How QSAs Assess Risk
   Given the complexity of SAQ changes, PSP responsibilities and merchant obligations, it helps when your approach is understood and trusted by QSAs and aligned with how they evaluate eSkimming controls in the field.

When those elements are in place, PCI DSS 4.0.1 becomes less of a paperwork problem and more of what it was meant to be in the first place: a lever to reduce real world fraud and data theft.

A Practical Way Forward

If you are still scrambling on 6.4.3 and 11.6.1, you are not behind so much as you are in crowded company. Most organizations are still figuring out what these requirements really mean for their architecture, their third party ecosystem and their compliance model.

A useful starting point is to:

1. Get visibility. Use an external assessment to baseline which scripts are running on your site today, what they are doing and where they sit relative to payment flows and sensitive data.
   
2. Engage your QSA and PSP. Make sure everyone has the same understanding of scope, SAQ strategy and who is responsible for which parts of the eSkimming controls.
   
3. Adopt a behavior based control, not a DIY CSP/SRI build. Independent reviews and real world experience show that purpose built, behavior based controls are faster to deploy, easier to operate and more effective at actually stopping attacks than homegrown CSP/SRI projects.
   
4. Use PCI DSS 4.0.1 as a floor, not a ceiling. Meeting the letter of 6.4.3 and 11.6.1 on payment pages alone may be “compliant,” but it will not eliminate the risk. The attackers are aiming at your whole site, not just your checkout form.

If you want help turning this from a confusing set of requirements into a concrete 30 day action plan, there are platforms and partners built specifically for this problem that can get you from assessment to protection in weeks, not quarters.

PCI DSS 4.0.1 is not perfect, and in some areas it does risk giving organizations a false sense of security. But with the right controls and a prevention first mindset, you can satisfy the standard and actually reduce eSkimming risk at the same time.

Request a demo or talk with our team today.

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.

Download the Guide