by Source Defense
For years, the payment security industry has framed eSkimming as a checkout problem. The logic seemed sound: attackers want payment data, so defend the payment page. That assumption has shaped PCI DSS 4.0.1 requirements, guidance from the Council, product architectures, and organizational investment decisions.
The problem is that it was never just a checkout issue and despite years of warnings from researchers and vendors in the know, the DSS didn’t evolve.
Modern eSkimming campaigns don’t need to compromise the payment page to succeed. In fact, the overwhelming majority of successful attacks begin outside of it. This isn’t a theoretical concern or a future risk – it’s what Source Defense and its partners are observing at scale today.
The data is clear: eSkimming attacks don’t need the payment page
As part of its contribution to the 2024 Verizon Payment Security Report, Source Defense analyzed approximately 7,000 of the world’s largest websites. Across those environments, researchers identified roughly 130,000 third-party scripts executing in the browser. What’s most important is where those scripts ran.
The analysis showed that the majority of scripts – more than half – execute across the site-wide footprint, not exclusively on payment pages. Of those scripts, 17,000 were observed accessing sensitive data, including PII, credentials, and payment-related fields.
This alone should challenge the idea that payment-page-only protection is sufficient. If the scripts with the broadest reach and greatest access run before checkout, that is where attackers will – and do – focus.
Independent forensic data reinforces this conclusion. In a large-scale review of 2,000 eSkimming investigations, SecurityMetrics found that 100% of cases involved compromise outside the payment page, most often on the referring page or elsewhere on the site.
In other words, if your defensive strategy assumes the payment page is the primary battlefield, you are defending the wrong terrain.
Why attackers prefer upstream pages
Upstream pages offer attackers three critical advantages.
First, they provide more opportunity. Users spend far more time interacting with product pages, account creation flows, search fields, and cart pages than they do on checkout. That time translates into more data.
Second, upstream pages often contain richer context. Email addresses, credentials, loyalty identifiers, addresses, and behavioral signals are all valuable – sometimes more valuable than card data alone.
Third, upstream pages tend to be less tightly controlled. Because of how the DSS is written, organizations apply stricter monitoring, and security controls to checkout while leaving the rest of the site comparatively open.
Once attackers gain a foothold in site-wide JavaScript, they can do far more than skim fields. As Source Defense research explains, compromised scripts can dynamically alter site behavior: replacing checkout buttons, injecting fake forms, recording keystrokes, staging data in storage, and redirecting users to attacker-controlled flows – all without ever touching the legitimate payment page.
Why iFrames and “payment isolation” don’t solve the problem
Many organizations take comfort in isolating payment pages using iFrames or hosted payment fields. While iFrames reduce risk in narrow scenarios, they do not address the broader attack surface.
Site-wide JavaScript still runs in the parent page. Once compromised, it can modify user journeys, collect data before the iFrame loads, or manipulate the flow so users never reach the protected payment experience at all.
This is why focusing solely on payment page isolation creates a false sense of security. Attackers don’t need to break the vault if they can intercept users before they reach the door.
Site-wide protection is not “more expensive” – it’s just good security
One of the most persistent objections to site-wide protection is cost or complexity. In practice, that objection doesn’t hold up.
Source Defense consistently advises clients that the incremental cost difference between protecting payment pages and protecting the full site is minimal, especially compared to the risk reduction achieved.
More importantly, a payment-page-only strategy creates governance risk. It forces organizations to justify why they knowingly leave large portions of the customer journey exposed—even as data flows and attacker techniques make those areas increasingly valuable targets.
The real framing: payment page vs. payment flow
This is why Source Defense and its QSA partners advocate moving from a “payment page” mindset to a payment flow and site-wide model. Once JavaScript is compromised anywhere in the flow, the entire journey becomes malleable to an attacker.
The question organizations should be asking is no longer “Is checkout protected?”
It’s “If an attacker compromises site-wide JavaScript, do we still have control?”
If the answer is no, the risk remains – regardless of how well-defended the payment page appears.
Conclusion
Site-wide protection isn’t a luxury or a future-state aspiration. It’s a response to how modern eSkimming actually works. The data from Source Defense research, Verizon PSR analysis, and third-party forensics points in one direction: attacks originate upstream, spread laterally, and succeed long before checkout.
Organizations that continue to focus narrowly on payment pages aren’t saving money. They’re accepting blind spots attackers have already learned to exploit.
Ready to stop eSkimming and simplify PCI DSS 4.0.1 compliance?
If you operate or embed payment pages, Requirements 6.4.3 and 11.6.1 are not “nice to have.” They are the bar your assessors will measure. The fastest path is to get full visibility into every script, prove authorization and integrity, then continuously detect and block tampering.
With Source Defense, PSPs and eCommerce platforms can:
- Automatically inventory and manage payment page scripts (6.4.3)
- Continuously monitor for tampering and alert or block in real time (11.6.1)
- Produce audit-ready evidence without turning your teams into full-time script librarians
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.