Category: Incident Response and Skimming

Digital Skimming

Also known as: Web Skimming, Magecart Attacks, E-skimming, Online Card Skimming

Simply put

Digital skimming is a form of online theft in which criminals plant malicious code on a merchant's website, most often on checkout or payment pages, to secretly capture the card and personal details customers type in. It is the internet-based counterpart to physical card skimming, replacing hidden hardware devices on ATMs or terminals with hidden code on web pages. The stolen information can then be used for card-not-present fraud or sold to other criminals.

Formal definition

Digital skimming refers to the deployment of unauthorized malicious code (often JavaScript) onto an e-commerce merchant's web application or its client-side dependencies, typically targeting checkout and payment form pages, in order to harvest payment card data and other sensitive data as it is entered into web forms. The technique is commonly associated with the Magecart threat activity and frequently exploits compromised first-party code or third-party/supply-chain scripts loaded into the payment page. Because the capture occurs client-side in the customer's browser, the harvested data may include cardholder data such as PAN, cardholder name, and expiration date, and can also capture sensitive authentication data such as CAV2/CVC2/CVV2/CID entered during checkout; the exact data exposed depends on what the affected page collects. Note that this term describes an attack technique and threat activity, not a PCI DSS control; the specific requirements addressing protection and monitoring of payment page scripts differ between PCI DSS versions and should be confirmed against the current published standard.

Why it matters

Digital skimming targets the point in an online transaction where customers are most exposed: the moment they type payment card details into a checkout or payment form. Because the malicious code executes client-side in the shopper's browser, the theft can occur even when the merchant's back-end systems appear secure and even when the page is served over HTTPS. The data captured can include cardholder data such as PAN, cardholder name, and expiration date, and may also include sensitive authentication data such as CAV2/CVC2/CVV2/CID entered during checkout. Sensitive authentication data must not be stored after authorization, but a skimmer intercepts it in transit at the browser before those storage controls ever apply, which is what makes this technique particularly damaging.

The attack is difficult for both merchants and customers to detect. The compromised page typically continues to function normally, so there is often no visible sign that data is being exfiltrated. Compromises frequently originate not in the merchant's own code but in third-party or supply-chain scripts loaded into the payment page, meaning a merchant can be affected by a weakness it did not directly introduce. This is why digital skimming is closely associated with the Magecart threat activity and why it has drawn attention from card brands and law enforcement, including guidance published by organizations such as Visa, Mastercard, and Europol.

It is important to note that digital skimming describes an attack technique and threat activity, not a PCI DSS control. Requirements addressing the protection and monitoring of payment page scripts differ between PCI DSS versions, and the applicable requirements should be confirmed against the current published standard rather than assumed. No single control eliminates this risk; layered measures intended to protect and monitor client-side code may help reduce exposure but do not guarantee prevention.

Who it's relevant to

E-commerce Merchants and Merchant Risk Teams

Merchants operating online checkout pages are the primary targets of digital skimming, and they bear responsibility for the integrity of the code executing on those pages, including third-party scripts they load. Merchant risk teams should understand that a compromise may originate outside the merchant's own code base and that the affected page can continue to function normally while data is being stolen.

Security Engineers and Application Security Teams

Because digital skimming exploits client-side code and supply-chain dependencies, security engineers are responsible for measures intended to protect and monitor scripts loaded into payment pages. These measures may help reduce exposure but do not guarantee prevention, and teams should account for the possibility of compromised third-party libraries as well as first-party code.

Compliance Officers

Compliance officers should recognize that digital skimming is an attack technique, not a PCI DSS control. The specific requirements addressing protection and monitoring of payment page scripts differ between PCI DSS versions and should be confirmed against the current published standard rather than assumed from a fixed requirement number.

Fraud Analysts

Fraud analysts investigating card-not-present fraud may encounter patterns consistent with data harvested through digital skimming, where card details valid at the point of entry are later used or sold. Understanding this technique helps contextualize the source of compromised data, though attribution of any specific fraud event to skimming requires supporting evidence.

Acquirers and Payment Processors

Acquirers and processors have visibility into merchant populations and downstream fraud signals, and card brand guidance—such as that published by Visa and Mastercard—addresses digital skimming as an ongoing threat to online merchants. They play a role in communicating expectations to merchants regarding the security of their checkout environments.

Inside Digital Skimming

Malicious client-side script

JavaScript or similar code injected into a payment page or its dependencies that captures data as the customer enters it into the browser, typically before any server-side encryption or tokenization is applied.

Targeted data

Digital skimming commonly seeks cardholder data such as PAN, cardholder name, and expiration date, and may also attempt to capture sensitive authentication data such as CAV2/CVC2/CVV2/CID entered at checkout. Sensitive authentication data must not be stored after authorization even if encrypted.

Supply-chain injection vector

Compromise of third-party scripts, tag managers, content delivery networks, or other externally loaded resources that execute in the payment page context, allowing attackers to introduce skimming code without directly breaching the merchant's own servers.

Exfiltration channel

The mechanism by which captured data is sent to an attacker-controlled destination, often disguised to blend with legitimate traffic to evade detection.

Relevant PCI DSS controls

PCI DSS includes requirements intended to help address payment-page script integrity and change detection on e-commerce pages. The specific requirement numbering and wording differ between versions, so readers should confirm against the current published standard rather than assuming a fixed requirement number.

Common questions

Answers to the questions practitioners most commonly ask about Digital Skimming.

Is digital skimming the same as physical card skimming at a terminal or ATM?

No. Physical skimming involves a hardware device that captures data from a card's magnetic stripe or chip interface at a card-present acceptance point. Digital skimming, sometimes called e-skimming or Magecart-style attacks, occurs in card-not-present environments where malicious code is injected into a website's payment page or a third-party script it loads, harvesting cardholder data and sensitive authentication data such as CVV2/CID as a customer enters it. The two share the goal of stealing payment data but operate through entirely different vectors, and controls that address one do not necessarily address the other.

Does using HTTPS or TLS on a checkout page prevent digital skimming?

No. TLS is intended to protect data in transit between the customer's browser and the server, but digital skimming typically captures data in the browser before it is transmitted, or through a compromised script that runs in the page's context. Encrypted transport does not detect or block malicious code executing client-side. Addressing digital skimming requires additional measures such as script integrity controls, monitoring, and change detection, and readers should confirm applicable requirements against the current published PCI DSS.

How can we detect unauthorized changes to scripts on our payment pages?

Common approaches include maintaining an inventory of scripts authorized to load on payment pages, justifying why each is present, and assuring their integrity through techniques such as monitoring for unexpected changes. Current PCI DSS versions include requirements addressing payment page scripts and change-or-tamper detection mechanisms; because requirement numbering and wording differ between versions, confirm the specific applicable requirements against the current published standard. These controls help reduce the window in which malicious code goes unnoticed but do not guarantee immediate detection.

How do third-party and fourth-party scripts affect our digital skimming risk and PCI DSS scope?

Payment pages often load scripts from third parties, and those scripts may in turn load additional code from fourth parties, expanding the attack surface beyond what the merchant directly controls. Scripts executing in the context of a payment page can potentially access data entered by the customer. Whether and how these elements affect PCI DSS scope depends on the implementation and how the acceptance is architected, so scope determination should be based on validated design rather than assumptions, and confirmed against the current published standard.

Can a Content Security Policy stop digital skimming attacks?

A Content Security Policy may help mitigate certain injection scenarios by restricting the sources from which scripts can load and where data can be sent, and it can support monitoring through violation reporting. However, it is not a complete control: an attacker who compromises an already-permitted script source, or who operates within allowed origins, may not be blocked. CSP is best treated as one layer alongside script inventory, integrity assurance, and monitoring rather than as a standalone solution.

Does redirecting checkout to a hosted payment page or iframe eliminate our exposure to digital skimming?

Delegating cardholder data entry to a payment service provider's hosted page or iframe can reduce the merchant's direct handling of that data, but it does not automatically eliminate exposure. The merchant's own pages that deliver or frame the payment element can still be manipulated to redirect customers, overlay fields, or alter how the hosted element loads. The effect on risk and on PCI DSS scope depends on the specific implementation and validation, not on the label of the integration method alone.

Common misconceptions

Encrypting or tokenizing data on the server protects against digital skimming.

Digital skimming typically captures data client-side in the browser before server-side encryption or tokenization is applied, so those transforms do not by themselves prevent this capture. Their effect depends on where and how they are implemented and validated, not on the label alone.

Digital skimming only affects merchants who fail to secure their own web servers.

Many incidents originate from compromised third-party scripts, tag managers, or content delivery resources loaded into the payment page, meaning a merchant's own infrastructure can be intact while injected code still executes in the customer's browser.

A single control such as 3-D Secure or a web application firewall eliminates digital skimming risk.

These controls address different points and risks in a transaction and may reduce but do not guarantee elimination of client-side skimming. Layered controls with known false-positive and false-negative trade-offs are more realistic than reliance on any one measure.

Best practices

Inventory and monitor all scripts executing on payment pages, including third-party and dynamically loaded resources, and maintain an authorized baseline to detect unexpected changes.

Implement payment-page script integrity and change-detection controls consistent with the current published PCI DSS requirements, confirming exact requirement numbering against the version in effect.

Restrict and vet third-party code loaded into checkout flows, applying integrity mechanisms and limiting scripts to only those necessary for the payment page to function.

Ensure sensitive authentication data such as CVV2/CVC2/CAV2/CID is not retained after authorization, and validate that no capture or storage path violates this, since these data must not be stored even when encrypted.

Monitor for anomalous outbound connections from payment pages that may indicate exfiltration, recognizing that detection controls carry false-positive and false-negative trade-offs.

Establish an incident response process for suspected client-side compromise, including rapid removal of malicious scripts, and coordinate with acquirers and card brands whose rules on notification and liability vary by region and change over time.