Web skimming and e-skimming protection

Web skimming is an attack in which malicious JavaScript running on a checkout page copies payment card details as the customer enters them and sends the data to a server the attacker controls, while the purchase completes normally. It is the digital equivalent of a physical skimmer fitted over an ATM card reader, and you will see the same technique called e-skimming in PCI SSC and FBI advisories, digital skimming in analyst reports, and formjacking when the emphasis is on the mechanism. Because the card is read in the browser and posted from the browser, the theft leaves no trace in your application logs and produces no failed transactions, which is why these attacks commonly run for weeks before anyone notices.

These three terms describe one technique and differ mainly by who is speaking. Security vendors say web skimming. Regulators, card brands and law enforcement tend to say e-skimming, which is also written eskimming without the hyphen. Analysts sometimes say digital skimming. Magecart names the threat actors rather than the technique, and formjacking names the specific mechanism of hijacking a form. If you are comparing vendors and they each use a different word, they are almost certainly describing the same thing.

The exfiltration never touches your server, so a WAF never sees it. The request happens in the visitor's browser, which is the only place it can be observed.

The script attaches a listener to the payment form, or replaces the form outright with one that looks identical. As the customer types, values are copied. Exfiltration is then whatever the attacker finds convenient: an image request with the data encoded in the query string, a WebSocket, a fetch to a lookalike domain, or a beacon fired on page unload so it survives navigation.

Encoding is normal. Base64, simple XOR, and splitting the payload across several requests are all common, specifically so that a human glancing at network traffic sees nothing obviously card-shaped. This is one reason "we would notice a request to a strange domain" is optimistic in practice.

Detection is necessary and it is not the first move. The cheapest win available on most checkouts is removing scripts that do not need to be there. Marketing tags, chat widgets, heatmaps, A/B frameworks and legacy pixels accumulate on payment pages because nobody owns the decision to remove them, and each one is both a compliance line item and an attack path.

Writing a business justification per script, which 6.4.3 requires anyway, tends to produce this clean-up for free: a surprising number of scripts have no answer to "what breaks if this is removed".