What Is Magecart Web Skimming?

Web skimming or e-skimming is theft of payment or account information by malicious code executing in an e-commerce page. PCI SSC notes that “Magecart” is an umbrella term used for multiple criminal groups and, more broadly, for this style of attack.

The malicious code may be inserted directly into the merchant application or arrive through a compromised third-party script, plugin, tag manager, analytics dependency or other browser-executed supply-chain component.

How a Web Skimming Attack Works

A typical attack chain has three phases: compromise the page or one of its trusted dependencies, observe sensitive form data in the browser, then exfiltrate selected values to attacker-controlled infrastructure. The customer may see a normal checkout and the merchant’s backend may process the legitimate transaction successfully, making server-only monitoring insufficient.

Common Magecart / E-Skimming Entry Paths

Magecart Detection Signals

• Unexpected new or modified JavaScript on checkout/payment pages.
• Changes to script source domains, integrity attributes or security-impacting HTTP headers.
• New browser network destinations receiving form-like or encoded data.
• Scripts reading sensitive form fields without a documented business need.
• Payment-page DOM changes outside authorized deployment windows.
• Third-party script hashes/content changing without a corresponding approved vendor update.
• Customer reports of card fraud correlated with recent checkout sessions.

PCI DSS 4.0.1 and E-Skimming Controls

PCI SSC’s current e-commerce guidance focuses directly on browser script risk. Requirement 6.4.3 addresses management of payment-page scripts—including authorization, integrity and inventory/justification—and Requirement 11.6.1 addresses detection of unauthorized changes to security-impacting HTTP headers and payment-page content as received by the consumer browser.

These controls are relevant because a server can be healthy while the browser executes changed or third-party code that steals data. Compliance scope and validation should still be confirmed with the organization’s assessor, acquirer or payment brand.

PCI SSC changed SAQ A reporting in 2025: Requirements 6.4.3 and 11.6.1 were removed from SAQ A itself and replaced with an eligibility criterion addressing susceptibility to script attacks. The underlying PCI DSS requirements still remain in the standard. Organizations should confirm their applicable validation method and scope with the appropriate compliance-accepting entity.

Magecart Prevention and Payment-Page Hardening

• Maintain an inventory of scripts allowed to execute on payment pages and document why each is needed.
• Minimize third-party JavaScript on pages that can access payment/account data.
• Use Subresource Integrity where it fits the delivery model and understand that dynamic script loaders can escape simple SRI coverage.
• Use a restrictive Content Security Policy to constrain script and network destinations, while recognizing that an allowed compromised script still executes with page privileges.
• Monitor payment-page content and security-relevant headers for unauthorized change.
• Protect CMS, tag-manager, CI/CD and deployment credentials with strong authentication and least privilege.
• Prefer payment architectures that minimize the merchant page’s direct access to card data when business requirements allow.

CSP and Subresource Integrity: Useful Controls With Important Limits

Content Security Policy (CSP) can reduce where scripts are allowed to load from and where browser code can connect, while Subresource Integrity (SRI) can require a fetched external resource to match an expected cryptographic hash. Both are useful controls for payment-page hardening, but neither should be treated as a complete Magecart solution.

SRI works best for versioned, immutable external scripts. It becomes operationally difficult when a vendor intentionally changes a resource at a stable URL, and it does not protect first-party scripts that are legitimately changed by a compromised deployment pipeline. CSP can restrict unapproved origins, but malicious code already executing from an allowed first-party or trusted vendor source may still operate within the permissions granted by the policy.

Use these mechanisms as part of a broader control set: minimize third-party JavaScript, authorize and inventory payment-page scripts, monitor the page as delivered to the browser, protect tag-manager/configuration accounts, and detect unexpected outbound destinations and DOM/script changes.

Tag Managers, CDNs and Other Browser-Side Control Planes

A payment page can be modified without changing the application repository. Tag-management accounts, CDN configuration, consent platforms, personalization systems and remotely hosted JavaScript can all influence what executes in the shopper’s browser. These systems should be treated as privileged deployment paths, not merely marketing tooling.

Require strong authentication and least privilege for administrative access, separate publishing from approval where practical, review third-party ownership changes, and alert on unexpected configuration or script-version changes. A legitimate tag-manager account used by an attacker can bypass file-integrity controls on the web server because the malicious code is introduced through an authorized integration path.

Inventory should therefore describe not only script URLs but also who can cause those scripts to change. This complements PCI DSS payment-page script governance by connecting each executing component to an owner, business justification, integrity/change mechanism and review process.

Third-Party JavaScript Risk

Third-party JavaScript runs with the privileges of the page’s origin and can often read or modify the DOM. OWASP therefore recommends explicit third-party JavaScript governance. A vendor domain on an allowlist is still trusted code; CSP only limits where scripts can load or send data according to the policy—it does not make an authorized script benign.

Reduce the number of third parties with access to sensitive pages, pin/verify immutable resources where possible, review remote configuration changes and isolate payment fields using well-designed hosted/iframe patterns when appropriate.

Related Ammune reading: API supply chain security and PII and PCI detection in API traffic.

Why Server-Side Monitoring Alone Can Miss Web Skimming

Magecart is unusual because the theft can occur entirely in the customer’s browser after the legitimate page is served. The checkout API may receive the correct transaction, backend logs may show normal status codes, and server file-integrity checks may remain clean if the malicious code comes from a third-party dependency or remote configuration.

Detection therefore needs a browser-facing view of the payment page: which scripts executed, which resources changed, which destinations received data and whether security-impacting page content or HTTP headers changed unexpectedly. This is the reason PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1 focus on payment-page script governance and change/tamper detection.

API telemetry remains valuable for a broader compromise—especially unusual checkout access, account takeover or server-side exfiltration—but it is complementary to browser/payment-page integrity controls rather than a replacement for them.

Magecart Control Ownership: Who Needs to Protect What?

Magecart defense often fails when every individual tool is configured correctly but no team owns the complete browser execution chain. Assign explicit owners for both the code and the external systems capable of changing what shoppers receive.

Incident Response for Suspected Web Skimming

• Preserve the affected page, script versions, HTTP headers and browser network evidence.
• Disable or isolate the compromised script/integration quickly without destroying evidence.
• Identify the first unauthorized change and the credential, dependency or deployment path used.
• Review which fields/data the script could access and where it transmitted them.
• Rotate affected deployment/admin credentials and remove persistence.
• Engage payment/compliance stakeholders and follow applicable breach/notification obligations.
• Rebuild trusted page assets and monitor for recurrence.

Where API Runtime Security Fits

Magecart is primarily a browser/payment-page integrity problem, so client-side script controls are essential. Ammune can complement that layer by monitoring APIs for unusual data access, exfiltration-like behavior and post-compromise application activity, especially where a skimming incident is part of a broader intrusion.

Magecart / Web Skimming Security Checklist

• Inventory every payment-page script.
• Authorize and justify required scripts.
• Assure script integrity where practical.
• Monitor browser-visible page/header changes.
• Reduce third-party code on sensitive pages.
• Use CSP and browser controls as defense in depth.
• Protect CMS/tag-manager/deployment credentials.
• Monitor checkout APIs and sensitive data flows.
• Have an e-skimming incident-response playbook.

Frequently Asked Questions

Primary References