37% of scanned domains showed active browser-layer security exposure indicators directly relevant to PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1 — on payment-scope pages specifically. The most alarming finding: keystroke event listeners attached to form fields by third-party scripts, present across a significant portion of flagged domains. This is the exact technical pattern Magecart-style skimmers use to intercept card data.
PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1 became mandatory on March 31, 2025. They are the most significant new client-side security controls introduced in the standard's history — requiring merchants to inventory and authorize every script on payment pages, and to maintain tamper-detection for those pages' scripts and HTTP headers.
We wanted to understand the actual state of compliance in the wild. Not self-reported survey data. Not theoretical risk assessments. Real scans of real merchant domains, measured against the specific indicators these requirements demand.
Here's the full picture — methodology, findings, what they mean, and what merchants should do about it.
Methodology
Scan type: All scans are passive and non-invasive. We analyze publicly observable client-side indicators — the same information any browser loads when visiting a page. No credentials are used, no private systems are accessed, no customer data is touched. This is functionally equivalent to viewing a website's source code in browser developer tools.
Page targeting: We crawl and categorize pages by function. Checkout, cart, payment, account, and login pages are flagged as payment-scope pages based on URL patterns, form field types, and page behavior. Sites without those page types are still scanned but findings are weighted differently. The 37% figure reflects domains where at least one payment-scope page had uncontrolled third-party script execution.
Script mapping: Scripts are mapped to the pages they execute on. A script appearing only on a blog page is treated differently than one executing on /checkout or /payment. We flag third-party scripts on payment-scope pages specifically because that's where PCI DSS 6.4.3 applies — the requirement is scoped to payment pages, not the entire domain.
Sample: 100,000+ e-commerce and merchant domains drawn from a proprietary global domain database, weighted toward English-language markets. Domains span all major e-commerce platforms including Shopify, WooCommerce, Magento, BigCommerce, and custom builds.
Top-Line Findings
The 37% figure represents domains where at least one payment-scope page — checkout, cart, login, account, or payment — showed uncontrolled third-party script execution relevant to 6.4.3 or 11.6.1. It is a conservative count. We did not flag a domain for a homepage finding that wasn't also present on a payment page.
Put another way: more than one in three merchant domains we scanned has a measurable client-side compliance gap on the pages where their customers type card numbers. Post-March 2025 enforcement deadline.
Findings Breakdown
Here are the specific indicators we measured, in order of prevalence across flagged domains:
| Finding | Relevant Requirement | Prevalence |
|---|---|---|
| No Content Security Policy with script-src directive on payment pages | 11.6.1 |
Majority
|
| Third-party scripts executing without Subresource Integrity controls | 6.4.3 |
Very common
|
| Google Tag Manager loading additional scripts dynamically on checkout pages | 6.4.3 |
Majority of flagged
|
| Keystroke event listeners on form fields by third-party scripts | 6.4.3 |
Significant minority
|
| No HSTS header on HTTPS payment pages | 4.2.1 |
Common
|
| Session cookies missing Secure or HttpOnly flags | 6.4.3 |
Common
|
Finding 1: The CSP Gap
The single most common finding across all scanned domains was the absence of a Content Security Policy with a script-src directive on payment-related pages. This was present on the majority of flagged domains.
A CSP with script-src enforcement is the primary technical mechanism for 11.6.1 compliance. Without it, there is no browser-enforced control over which scripts are permitted to execute on a payment page. Any injected script — whether from a compromised CDN, a tampered tag manager container, or a malicious browser extension targeting your checkout — executes without restriction.
Requirement 11.6.1 mandates a mechanism that detects unauthorized changes to HTTP headers and scripts on payment pages. A Content Security Policy that specifies allowed script sources is the most practical implementation of this control. Without a CSP, there is no baseline — and no way for the browser to enforce or alert on deviations from it. Every domain missing a payment-page CSP has a direct 11.6.1 gap.
Many of the domains we scanned had a CSP on their homepage. The same domains had no CSP on their checkout page. This is the pattern we described in our homepage vs. deep scan case study — a false sense of security created by scanning the wrong pages.
Finding 2: Scripts Without SRI
The second most common finding: third-party scripts executing without Subresource Integrity controls — including Google Tag Manager, Meta Pixel, and analytics scripts loading directly on checkout pages.
Subresource Integrity (SRI) is a browser security feature that allows you to specify a cryptographic hash for a script file. If the script's contents don't match the hash, the browser refuses to execute it. It's a direct control against supply-chain compromise — if an attacker modifies a script on an external CDN, SRI prevents the tampered version from running.
Google Tag Manager loads scripts dynamically at runtime. The actual scripts that execute are determined by GTM's container configuration — not your page's HTML. This means they cannot have SRI hashes applied. Every script GTM loads on a payment page is an uncontrolled third-party execution under Req. 6.4.3.
In every case where GTM was present on a checkout page, it was loading additional scripts dynamically — none with SRI controls. Analytics, advertising, session recording, chat, personalization. All executing without integrity enforcement on payment pages.
This doesn't mean GTM is malicious. It means GTM's architecture creates a structural compliance gap under PCI DSS 4.0.1 that most merchants are unaware of until someone specifically looks for it.
Finding 3: Keystroke Listeners on Payment Forms
This is the finding that should concern merchants most.
Across a significant portion of flagged domains, we identified third-party scripts that had attached keystroke event listeners — keyup, keydown, input events — to form fields on payment pages. This is the exact technical pattern modern Magecart-style web skimmers use to intercept card data before it's submitted to a payment processor.
A Magecart skimmer attaches JavaScript event listeners to payment form input fields. As a customer types their card number, the listener captures each keystroke and exfiltrates it to an attacker-controlled server — before the data is ever submitted to the payment processor. The same technical mechanism is used by legitimate session recording and analytics tools. From the browser's perspective, and from the perspective of network traffic analysis, the behavior is identical. The only difference is the destination of the data.
In the cases we identified, the scripts with keystroke listeners were legitimate analytics and session recording tools — not known malware. But they were executing on payment pages with direct access to payment form fields, without SRI controls, without CSP restrictions, and in several cases sending beacon requests to third-party origins while the payment form was active.
A QSA reviewing these findings would flag them. An acquirer reviewing them post-breach would flag them. The fact that the scripts are "legitimate" is not a defense — it's an argument for removing them from payment pages entirely.
Finding 4: Platform Compliance Is Not Browser-Layer Compliance
One of the most consistent patterns across the dataset: Shopify, WooCommerce, and Magento stores showing significant client-side exposure despite being hosted on platforms marketed as PCI compliant.
Platform PCI compliance covers the server infrastructure — the hosting environment, the payment processing integration, the data storage layer. It does not cover the scripts that execute in the browser on the merchant's storefront. Those scripts are the merchant's responsibility, and they are explicitly what Requirements 6.4.3 and 11.6.1 target.
- Shopify handles payment processing compliance — but Shopify themes load third-party scripts from apps installed by the merchant. Those scripts execute on checkout pages. Shopify's compliance does not extend to them.
- WooCommerce runs on WordPress — which means any plugin can inject scripts into any page, including payment pages. The average WooCommerce checkout page we scanned had significantly more third-party script execution than a comparable Shopify store.
- Magento's extensibility is a compliance liability — extensions routinely inject scripts site-wide, including on checkout. The merchant, not Magento, is responsible for auditing and controlling those scripts under 6.4.3.
What These Findings Mean for Merchants
The March 2025 enforcement deadline has passed. These are not future requirements — they are current obligations. A merchant who cannot demonstrate compliance with 6.4.3 and 11.6.1 today is operating with a documented gap against the active PCI DSS standard.
The practical consequences:
Level 2 merchants complete annual SAQs. Level 1 merchants undergo QSA assessments. Both require accurate attestation of 6.4.3 and 11.6.1 controls. A SAQ filed without actually validating these controls is an inaccurate attestation — creating liability for the individual who signed it, not just the organization.
If a card skimmer is discovered on a merchant's checkout page — and the forensic investigation reveals uncontrolled third-party scripts, no CSP, no SRI controls — the absence of 6.4.3 and 11.6.1 compliance becomes a central factor in determining liability, fines, and forensic costs. PCI DSS compliance isn't just a checkbox — it's a legal defense posture.
The most common findings — missing CSP, scripts without SRI, GTM on checkout pages — have well-established remediation paths. Implementing a CSP with script-src enforcement, removing GTM from payment pages, and building a formal authorized script inventory addresses the majority of 6.4.3 and 11.6.1 gaps. The challenge is identifying them accurately in the first place.
About This Research
ClientSideIntel operates a continuous automated browser-layer scanner across a proprietary global domain database. Our scanner uses a headless browser to load pages exactly as a real visitor's browser would — executing JavaScript, loading third-party resources, and capturing the full client-side security state of each page.
All scans are passive. We analyze only what is publicly served to any visitor. We do not access private systems, authenticate to merchant accounts, or capture customer data. The findings in this research reflect publicly observable client-side security indicators only.
If you want to see your own domain's results — specifically your checkout, cart, login, and payment pages — the CSI Deep Scan produces a full PDF report covering every indicator described in this research, mapped to specific PCI DSS 4.0.1 requirements, with a prioritized remediation roadmap.
See where your payment pages actually stand.
Full PCI DSS 4.0.1 client-side assessment of your checkout, cart, login, and payment pages. The same indicators measured in this research, applied to your domain. PDF delivered automatically.
Order Deep Scan — $79 →