by Source Defense
For years, teams have leaned on Content Security Policy (CSP) and Subresource Integrity (SRI) to defend the browser. For client-side attacks like eSkimming, they are not enough.
Today’s attacks rarely arrive from obvious, unknown domains. Adversaries compromise legitimate, whitelisted sources such as analytics, tag managers, chat widgets, or CDNs and inject malicious JavaScript that executes in the user’s browser. CSP and SRI trust those sources by design. That creates a gap attackers exploit.
Static Controls in a Dynamic Threat Environment
CSP limits where scripts can load from. SRI verifies a script’s hash. Both are static controls in highly dynamic environments.
Modern sites change often. Each update means new hashes, new allowlists, and operational overhead. Meanwhile, attackers target the scripts you already allow, harvesting data at the point of input via keylogging, injected fields, or silent exfiltration. This is exactly the client-side blind spot PCI DSS 4.0.1 brought into scope with requirements 6.4.3 and 11.6.1.
What Industry Guidance Actually Says
PCI guidance recognizes CSP/SRI as possible techniques, but leading assessors consistently caution that they are operationally burdensome and reactive. The PCI Council’s eCommerce working materials and expert taskforces warn not to rely on CSP or SRI alone for eSkimming risk because they do not monitor what scripts do and they lack built-in reporting and behavior controls.
Independent QSAs have published practical direction as well. Coalfire recommends controls that cover the entire payment flow, and calls out the value of tamper-resistant, browser-resident measures that can alert and block malicious script behavior in real time, aligning with 6.4.3 and 11.6.1 outcomes.
The Hidden Cost of “Do-It-Yourself” CSP/SRI
In-house CSP/SRI programs demand constant tuning. Teams must inventory, justify, and re-authorize scripts, maintain hashes, and chase breakage when vendors update code. Even then, CSP/SRI tell you where a script came from, not what it is doing inside the session. That leaves gaps for data entry capture, credential harvesting, and formjacking that occur before traffic reaches your server.
Move From Trust to Control: Behavior-Based Protection
Real protection comes from controlling script behavior in the browser, in real time. A behavior-based approach:
- Authorizes scripts and continuously inventories them to meet 6.4.3.
- Monitors for unauthorized changes to payment pages and headers, issues alerts, and blocks malicious activity to meet 11.6.1.
- Prevents exfiltration and keylogging at the point of input, even when a “trusted” source is compromised.
How Source Defense Helps
Source Defense pioneered eskimming security and is trusted by leading brands and QSAs. The platform inventories and justifies scripts, enforces behavior policies, and blocks unauthorized actions automatically. It supports PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 with push-button evidence for audits, and typically requires minimal ongoing effort.
Independent reviews by Coalfire and VikingCloud confirm the platform’s ability to support the intent of the PCI controls and to prevent client-side data theft behaviors during testing when configured appropriately.
If you need a fast path, the 30-day action plan gets you from discovery to deployment with compliance-ready dashboards and training for your audit teams.
Bottom Line
CSP and SRI can harden a site, but they are not effective eSkimming controls on their own. They do not detect compromised script behavior or stop data theft in real time. If your goal is true client-side security and clean PCI DSS 4.0.1 evidence, move beyond trust-based controls to behavior-based protection that prevents exfiltration at the browser.
Take control of your eSkimming security. [Request a demo 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.