Category: Incident Response and Skimming

E-Skimming

Also known as: Digital Skimming, Payment Skimming, Web Skimming

Simply put

E-skimming is a cyberattack in which criminals plant malicious code on the payment pages of an e-commerce website to secretly capture customers' payment card data as they enter it during checkout. Because the theft happens inside the customer's browser or on the checkout page itself, shoppers and merchants often do not notice it while it is occurring. Stolen information can include credit card details and personally identifiable information.

Formal definition

E-skimming refers to the unauthorized injection of malicious code into e-commerce payment card processing web pages to intercept and exfiltrate cardholder data—and potentially other personally identifiable information—as it is submitted during the checkout flow. In practice, the attack captures data at the point of entry (for example, within the client-side checkout page rendered in the customer's browser), which may include PAN, cardholder name, and expiration date, and depending on the page's data collection, may reach sensitive authentication data such as CAV2/CVC2/CVV2/CID entered by the customer. The specific vector, scope of captured data, and applicable PCI DSS controls depend on the site architecture and integration model; readers should confirm control requirements against the current published PCI DSS. Evidence in this packet does not specify injection techniques, prevalence, or quantitative impact.

Why it matters

E-skimming targets the exact moment a customer submits payment card data during online checkout, capturing credit card details and personally identifiable information at the point of entry. Because the malicious code executes inside the customer's browser or on the checkout page itself, the theft is often invisible to both shoppers and merchants while it is happening, allowing an attack to continue undetected and quietly exfiltrate data over an extended period.

The data at risk can include cardholder data such as PAN, cardholder name, and expiration date, and depending on what the page collects, may reach sensitive authentication data such as CAV2/CVC2/CVV2/CID entered by the customer. This matters because sensitive authentication data must not be stored after authorization even when encrypted, yet an e-skimming attack captures it in the clear as the customer types it—outside the merchant's normal storage and control boundaries. That makes prevention and detection at the client-side checkout layer, rather than reliance on data-at-rest controls, central to reducing exposure.

The applicable PCI DSS controls depend on the site's architecture and integration model, and requirement wording and numbering differ between versions, so teams should confirm obligations against the current published standard rather than assuming a fixed requirement. The evidence available here does not establish prevalence figures or quantitative impact, and any such numbers would depend on source, period, and methodology.

Who it's relevant to

E-commerce merchants

Merchants operating online checkout pages are the direct targets of e-skimming, since the malicious code is planted on their payment card processing web pages. They bear responsibility for the integrity of the checkout flow and for detecting unauthorized code that captures customer payment data during entry.

Security engineers and web application teams

Teams responsible for the client-side checkout page and its integrations need to focus on the point of data entry rendered in the customer's browser, where e-skimming operates. Because the attack is often invisible while occurring, monitoring and integrity controls at the payment page layer are central to reducing exposure.

Compliance officers

Those managing PCI DSS obligations must map applicable controls to their specific site architecture and integration model, and confirm requirements against the current published standard, since requirement wording and numbering differ between versions. The risk that e-skimming can capture sensitive authentication data as the customer types it is particularly relevant given the prohibition on storing such data after authorization.

Fraud analysts and merchant risk teams

Analysts investigating compromised card data need to recognize e-skimming as a source of stolen credit card and personally identifiable information taken directly at checkout. Understanding this vector helps distinguish client-side data theft from other fraud and breach sources when tracing how card data was exposed.

Inside E-Skimming

Client-Side Script Injection

The core technique of e-skimming, in which an attacker injects or modifies JavaScript that executes in the customer's browser on a payment or checkout page. The malicious script captures data as the cardholder enters it, before or in parallel with legitimate processing.

Targeted Data

E-skimming typically harvests cardholder data such as PAN, cardholder name, and expiration date, along with sensitive authentication data such as CVV2/CVC2/CID entered during a card-not-present transaction. Because sensitive authentication data must not be stored after authorization, its capture in transit by an attacker is a distinct and serious exposure.

Supply-Chain and Third-Party Scripts

Many e-skimming compromises originate through third-party or fourth-party JavaScript, such as chat widgets, analytics, tag managers, and content delivery networks. A single compromised dependency loaded into the payment page can introduce skimming code without altering first-party code directly.

Exfiltration Channel

The mechanism the attacker uses to send stolen data off the victim's browser, commonly an HTTP request to an attacker-controlled domain that may be disguised to resemble legitimate services. Exfiltration may be batched, obfuscated, or conditional to evade detection.

Relationship to PCI DSS Scope

E-skimming is associated with controls addressing payment page integrity and management of scripts loaded in the browser. PCI DSS has introduced requirements in this area; because requirement numbering and wording differ between versions and some requirements have phased applicability, practitioners should confirm the exact wording and dates against the current published standard rather than assuming a fixed number.

Common questions

Answers to the questions practitioners most commonly ask about E-Skimming.

Does e-skimming only affect the merchant's own servers, so server-side hardening alone stops it?

No. E-skimming commonly executes in the customer's browser via malicious or compromised client-side scripts, including third-party code loaded onto the payment page. Because the malicious code can run in the browser rather than on the merchant's servers, server-side hardening alone does not fully address it. Controls that address client-side scripts and monitor the content delivered to the payment page are also relevant. Confirm the specific script-management and monitoring expectations against the current published PCI DSS, because requirement numbering and wording differ between versions.

If the payment page uses TLS/HTTPS, is it already protected from e-skimming?

No. TLS protects data in transit between the browser and server, but e-skimming captures data within the browser before or as it is entered, typically through injected or compromised JavaScript. Encryption of the connection does not prevent a malicious script running in the page context from reading form fields. TLS and controls addressing client-side script integrity address different risks and are not substitutes for one another.

Which data elements are typically targeted by e-skimming on a payment page?

Malicious client-side code on a payment page can harvest whatever is entered into the form, which may include cardholder data such as the PAN, cardholder name, and expiration date, as well as sensitive authentication data such as CAV2/CVC2/CVV2/CID entered during a card-not-present transaction. Sensitive authentication data must not be stored after authorization, but e-skimming is a theft-at-entry technique that captures it as the customer types, which is a distinct exposure from stored-data risk.

How can a merchant reduce exposure to third-party scripts on the payment page?

Approaches that may help reduce exposure include inventorying and justifying every script authorized to run on the payment page, monitoring scripts for unauthorized changes or additions, and limiting the number of third-party components loaded where the card data is entered. Techniques such as restricting the browser context that handles card entry, for example through an iframe served by a payment provider, can reduce what the merchant page directly touches, though effects on PCI DSS scope depend on implementation and validation rather than the technique's label. Confirm the applicable script-management expectations against the current published standard.

What detection methods help identify an active e-skimming compromise?

Detection methods can include change-detection or integrity monitoring on payment page content and scripts, alerting on new or modified outbound connections from client-side code, and reviewing script inventories against an approved baseline. These controls involve trade-offs: overly broad monitoring can generate false positives from legitimate script updates, while narrow baselines can miss obfuscated or dynamically loaded malicious code, producing false negatives. No single detection control should be treated as eliminating the risk.

What is out of scope when addressing e-skimming, and what related controls remain necessary?

E-skimming specifically concerns theft of data entered on a web payment page, typically via client-side code, so it does not by itself cover card-present skimming at physical devices, account takeover, or stored-data protections. Addressing e-skimming does not remove the need for other controls such as protecting stored cardholder data under defined controls, prohibiting storage of sensitive authentication data after authorization, and applying appropriate authentication measures. Treat e-skimming controls as one layer among several rather than a comprehensive safeguard.

Common misconceptions

TLS/HTTPS on the checkout page prevents e-skimming.

Encryption in transit protects data moving between the browser and server, but e-skimming captures data within the browser itself, at the point of entry, before or alongside legitimate transmission. A page served over HTTPS can still execute a malicious script, so transport encryption does not address this attack vector.

If the merchant redirects to a hosted or iframed payment form, e-skimming is not a concern.

Redirection and iframes may reduce exposure, but the parent page and any scripts loaded into it can still be manipulated to intercept input, overlay fake fields, or alter the redirect. The degree of risk reduction depends on the specific implementation and validation, not on the label of the integration method alone.

E-skimming is only a problem in a merchant's own code.

A large share of e-skimming enters through third-party and fourth-party scripts loaded into the payment page. First-party code may be untouched while a compromised dependency introduces the skimmer, which is why script inventory and integrity management extend beyond code the merchant writes.

Best practices

Maintain an inventory of all scripts loaded on payment and checkout pages, including third-party and dynamically loaded dependencies, and justify why each is present.

Implement integrity controls for scripts, such as monitoring for unauthorized changes and using mechanisms that help confirm scripts have not been altered, and confirm the relevant PCI DSS requirements against the current published standard.

Reduce the number of scripts and third-party services running on pages that collect cardholder data or sensitive authentication data, minimizing the browser-side attack surface.

Consider integration approaches, such as hosted fields or redirects, that limit where card data is entered, while recognizing that these reduce rather than eliminate risk and must still be monitored.

Deploy client-side monitoring and change detection intended to identify unexpected script behavior or exfiltration attempts, and tune it to manage false-positive and false-negative trade-offs.

Establish an incident response process for suspected payment page compromise, including the ability to identify affected data and coordinate with acquirers, processors, and card brands per applicable network rules.