by Source Defense
Content Security Policy and Subresource Integrity are often treated as foundational defenses against eSkimming attacks. They. Do. Not. Work.
Whether homegrown in nature or as the foundation of commercially available eSkimming solutions, it is critical for you to understand that these solutions do not hold up to eSkimming attacks, and in fact, they turn a blind-eye to the way these attacks have long been perpetrated.
While both standards may serve legitimate purposes, attackers have spent years learning exactly how to work around them – and in many cases, directly through them. The PCI DSS as it stands right now erroneously references these approaches as reference examples – point blank, the DSS gets it wrong and the PCI Security Standards Council needs to make a change to stop misguiding merchants, merchant acquirers, card associations and QSAs.
Modern eSkimming campaigns don’t “break” CSP or SRI. They exploit the assumptions those controls were built on.
The core weakness: trust once granted is rarely revoked
CSP is fundamentally an allowlist. Once a domain is trusted, anything served from that domain is trusted as well. This creates a powerful incentive for attackers to operate inside trusted infrastructure rather than attempting to introduce new, suspicious sources.
Source Defense research has repeatedly documented attacks leveraging:
- Compromised third-party vendors
- Legitimate tag managers
- Well-known CDNs and cloud platforms
When malicious code is delivered through an allowed source, CSP provides no protection. The browser does exactly what it was told to do.
Why SRI breaks down in modern environments
Subresource Integrity assumes that scripts are static and predictable. In practice, third-party scripts change constantly. Vendors update code, add features, perform experiments, and optimize delivery.
Because SRI requires hashes to be updated with every change, it becomes operationally infeasible at scale. Most organizations either abandon SRI for third-party scripts or apply it so selectively that it provides little coverage.
Attackers understand this reality. They target scripts that are exempt from SRI or exploit delivery mechanisms where hashes are impractical.
Common bypass patterns observed in the wild
Across multiple investigations, Source Defense has observed recurring techniques that bypass CSP and SRI without triggering obvious alarms:
- Malicious logic embedded into already-allowed scripts
- Script chaining through trusted loaders
- Conditional execution triggered only under specific URLs or user actions
- Data staged locally and exfiltrated later, outside CSP-monitored flows
- Use of legitimate endpoints for data transmission
These techniques exploit the fact that CSP and SRI evaluate where code comes from, not what it does.
Why bypasses keep working
The uncomfortable truth is that CSP and SRI were never designed to stop malicious behavior inside trusted code. They were meant to reduce accidental exposure, not defend against adversaries abusing the supply chain.
As long as attackers can compromise vendors, hijack tag managers, or abuse legitimate platforms, static policies will remain easy to sidestep.
What actually works
Stopping these attacks requires shifting focus from origin to behavior. Instead of asking “Is this script allowed to load?” the more important question becomes “Is this script allowed to do this?”
Behavioral controls can detect and prevent:
- Unauthorized access to sensitive fields
- DOM manipulation around forms and buttons
- Unexpected network transmissions
- Runtime changes that violate policy
For true security against eSkimming – which should be a top priority for all payment security professionals given the amply evidence of attack proliferation, a behavioral based approach is the only way to address this issue.
See Behavioral eSkimming Protection in Action
If you are relying on CSP and SRI, you are still trusting the same delivery paths attackers abuse.
Request a demo and we’ll show you how Source Defense monitors what scripts do in the browser, not just where they come from. You will see how we help teams take control of payment-page scripts, block suspicious behavior, and produce audit-ready evidence for PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1.
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.