TL;DR: Magento PCI compliance
- Magento does not handle Requirements 6.4.3 and 11.6.1 for you. Every script on your checkout page needs an inventory entry, a business justification, and continuous integrity monitoring.
- ASV scans satisfy Requirement 11.3.2. They do not detect JavaScript threats on payment pages. Merchants who treat ASV scans as their primary security check are missing the controls that PCI DSS 4.0.1 actually requires for client-side risk.
- The most common Magento attack vector in 2024 and 2025 is WebSocket-based exfiltration via compromised extensions. It bypasses CSP, bypasses network monitoring, and is only visible to a tool that monitors the browser runtime directly.
What Is Magento PCI Compliance?
Magento merchants are not automatically PCI DSS compliant. While Magento Commerce Cloud handles infrastructure-level controls, merchants remain responsible for securing checkout pages against client-side attacks. PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1 require all scripts on payment pages to be inventoried, authorized, and monitored for integrity changes, controls Magento does not provide natively regardless of which payment extension you use.
The common misconception: merchants assume that using a certified payment extension, or delegating payment processing to a hosted payment page, satisfies PCI DSS. It reduces scope, but it does not eliminate it. Any Magento page that loads checkout functionality, or that sits in the cardholder data environment by virtue of loading third-party scripts, is in scope for Requirements 6.4.3 and 11.6.1.
The typical Magento checkout page loads tracking pixels, analytics tags, A/B testing tools, affiliate scripts, chat widgets, and payment library scripts. Each one is in scope. Each one requires an inventory entry with a business justification. Each one must be monitored for integrity changes between assessments.
PCI DSS Requirements Magento Merchants Commonly Miss
Requirement 6.4.3: Script inventory and authorization. Every script loaded on a payment page must be inventoried. The inventory must document the business justification for each script, confirm that each script is authorized, and include a method to verify that each script's integrity has not been changed. A static list in a spreadsheet does not satisfy this requirement: the inventory must reflect the live state of the payment page, because scripts change.
Requirement 11.6.1: Payment-page tamper detection. The merchant must have a mechanism that detects unauthorized changes to HTTP headers and payment-page content, and that alerts the responsible team within a defined timeframe. A periodic manual review does not satisfy this requirement. The mechanism must be capable of detecting a new script appearing, an existing script changing, or an HTTP header being modified between review cycles.
Both requirements became mandatory on 2025-03-31 and are now actively assessed. If your Magento store does not have a tool that produces continuous evidence for these requirements, your next PCI DSS assessment is at risk.
What Is an Approved Scanning Vendor (ASV)?
An Approved Scanning Vendor (ASV) is a company certified by the PCI SSC to conduct external vulnerability scans as required by PCI DSS Requirement 11.3.2. ASV scans probe external-facing network components for known vulnerabilities. They do not detect client-side JavaScript threats on payment pages, unauthorized third-party scripts, or the behavioral anomalies addressed by Requirements 6.4.3 and 11.6.1. Passing an ASV scan does not mean your Magento checkout is protected against Magecart-style attacks.
What ASV scans do: probe your external IP addresses and domains for known CVEs, open ports, misconfigured services, and network-layer vulnerabilities. A clean ASV report confirms that your server perimeter has no known exploitable vulnerabilities that are detectable from outside.
What ASV scans do not do: analyze any JavaScript executing on your payment pages, detect scripts that were not present during the last scan, verify that third-party scripts have not been modified since they were last approved, or observe what data scripts send to external endpoints during a real visitor session.
This gap is not a criticism of ASV scanning. It is a description of what the tool is designed for. The compliance controls that address client-side JavaScript threats are 6.4.3 and 11.6.1, not 11.3.2. A Magento store can pass every quarterly ASV scan while actively running a compromised script that is exfiltrating cardholder data in real time.
The Magento Attack Vector ASV Scans Cannot See
cside tracks active TTPs against Magento merchants. The most sophisticated attack pattern observed in 2024 and 2025 uses WebSocket connections for exfiltration instead of standard HTTP requests.
Why WebSockets bypass traditional defenses:
Standard Magecart attacks exfiltrate data via HTTP POST requests to attacker-controlled domains. CSP connect-src directives can block these if the attacker domain is not on the allowlist. Network monitoring tools can see the outbound POST and flag it.
WebSocket connections using the wss:// protocol are different. Many CSP configurations do not restrict WebSocket origins separately from HTTP origins. Network monitoring tools that are focused on HTTP traffic may miss wss:// connections entirely. The attacker maintains a persistent bidirectional channel to the victim's browser, can modify injected scripts on the fly without triggering a new page load, and can exfiltrate cardholder data continuously rather than in discrete POST requests.
The access vector: CosmicSting (CVE-2024-34102), disclosed in June 2024, allowed unauthenticated attackers to read server files from Adobe Commerce and Magento installations, including configuration files containing database credentials and API keys. Once credentials were obtained, attackers injected the WebSocket-based skimmer directly into Magento checkout pages. The patch for CVE-2024-34102 closes the initial access vector. It does not remove injected scripts already present. Merchants who patched the CVE but did not audit their payment-page scripts for post-exploitation artifacts may still be serving the skimmer.
The only detection layer that catches this attack is one that instruments the browser runtime directly: observing what scripts execute in real visitor sessions, what API calls they make, and where they send data, in real time, on every session.
How cside Protects Magento Checkouts
cside deploys as a single first-party JavaScript snippet on your Magento checkout pages. It monitors the browser runtime of every real visitor session and produces continuous evidence for Requirements 6.4.3 and 11.6.1.
For Requirement 6.4.3: cside maintains a live script inventory for every script that loads on each monitored page, including the business justification field, the authorization status, and the integrity hash at each load. When a new script appears, or an existing script changes, the inventory updates and an alert fires.
For Requirement 11.6.1: cside detects changes to payment-page scripts and HTTP headers in real time, in real visitor sessions, and generates a timestamped evidence trail that QSAs accept for the requirement.
For WebSocket-based attacks: because cside instruments the JavaScript runtime directly, it observes WebSocket connections established by scripts on the page regardless of whether they are visible in HTTP traffic logs or covered by CSP.
See how to comply with PCI 6.4.3 and 11.6.1 for the detailed implementation walkthrough.
