How e-skimming steals credit card data and how to stop it

What’s your vibe? Walking on air in a pair of happy socks? Or the exclusivity of a luxury watch on your wrist? Yeah, not even close.

But when you buy those socks or that watch online and your PII or payment card details fall into the wrong hands, the consequences are exactly the same.

Stolen payment card data creates a whole mess: contacting the issuer, blocking the card, assessing the damage. Because it's only when you're checking your statements that you notice something's wrong. And by then it's too late.

That's often the first moment merchants hear about the misuse of credit card information too. E-skimming attacks are usually well-prepared and stay hidden from merchant security systems. That's the blind spot of client-side security.

How does this happen without anyone noticing?

What Is E-Skimming? How Magecart attacks steal payment data

Skimming, or intercepting payment card data, isn't new, but it's taking on different forms. Attackers have expanded their territory: from payment terminals (ATMs and POS devices) to online transactions and software.

When skimming happens online in an e-commerce context, we call it e-skimming.

The action takes place in the user's browser, not on the merchant's server.

These are often well-prepared and sophisticated attacks: a specialty of certain hacker communities, also known as Magecart attacks. Their method: JavaScript injection on checkout pages.

To be clear: we're not talking about phishing or fake checkout pages here. This type of attack works differently. Attackers inject a few lines of JavaScript code that records what users enter on payment pages. They funnel that data to their own server, usually via a domain that closely resembles the legitimate merchant's. This style of attack was used against Ticketmaster and British Airways, among others.

What websites are vulnerable to e-skimming?

Generally speaking, any website that works with third-party scripts, especially when they run on login or checkout pages.

You might ask yourself whether it makes sense to review what those scripts are actually needed for. Which scripts are running on those pages exactly? Are marketing analytics tools that measure traffic really necessary during payment processing?

Every added script increases complexity and can make it harder to maintain oversight.

How does e-skimming work and where things go wrong

To understand how e-skimmers operate, we need to look at how online payments work.

When shoppers have loaded up their cart and are ready to order, they land on the payment page. There they fill in the form fields. That data is then encrypted and sent to the merchant and card issuer. If the transaction is approved, fulfillment begins.

What are the vulnerable moments? Data can be intercepted during transfer. Security protocols like HTTPS/SSL provide encryption and add security during transfer. If attackers get their hands on encrypted data, they can't do much with it unless they manage to decrypt it.

On the merchant's server side, security is also active and monitored.

What both merchants and card issuers don’t see is what happens in the user's browser.

Third-party security: how hackers inject e-skimming code

What if someone could watch while customers enter their details in the payment form fields? And then also manage to copy or exfiltrate that data?

Third-party scripts as an attack vector

E-commerce sites often use third-party tools for smooth checkout processing. There are all-in-one platforms like Shopify and WooCommerce.

Card issuers like Mastercard and Visa, or intermediaries like Klarna and PayPal, also add their solutions. Often in the form of scripts that don't run on the e-commerce business's server but on third-party servers.

For completeness: those scripts can in turn add other scripts without anyone noticing.

You see the problem: it's not easy for merchants to maintain oversight of all the scripts running on or through their e-commerce website.

Why Third-Party Scripts are so dangerous

What's the danger, really?

In an optimal scenario for the attacker: they create a script that lets them see what users enter in the payment form. Bingo. They now see PII and the card number, expiration date, and CVC code.

If they manage to copy and exfiltrate that to their own server, the loot is secured. That's the system, and it sounds simple, but it requires a sophisticated process.

How trusted sources become the source of a supply chain attack

An outdated or neglected script can be taken over by attackers. This could be shopping cart software, a payment plugin, marketing and analytics tools, or open-source libraries.

At that point they have free rein. They gain access to the source code, modify the script to their liking, and inject malicious code, for example in an update. The browser loads it anyway.

This is how malicious code spreads through trusted software or vendors: a textbook example of a supply chain attack.

Why browsers blindly execute malicious code

The browser itself makes no distinction between its own scripts and third-party scripts. The script keeps running and to everyone involved, everything appears normal. No alarm bells go off.

The merchant sees it's a known script from a trusted external party. Integration often happens automatically too: via CDN, npm, or a plugin update.

It looks like business as usual. But it's actually a client-side attack: the manipulated code gets rolled out through the user's browser.

Why standard server-side security doesn't help

The malware doesn't run on the merchant's server. It runs in the customer's browser with the same rights and privileges as the merchant's own code.

JavaScript is accepted and executed in the DOM. Merchant and card issuer systems often have no visibility into this.

When the browser executes a malicious script, all hell breaks loose.

How to detect e-skimming attacks and why that’s hard

The skimmer hides in plain sight

The skimmer watches along: it sees what's entered in the form fields and listens to submit events.

The data gets sent to the merchant and payment processor and to the digital thieves. They can quietly continue their business because it can take a while before anyone realizes something's off. Often that's only when customers check their bank statements and payment overviews, weeks later.

Suspicious script behavior and network requests

The skimmer itself can often do its work quietly for weeks or months. That's where the sophisticated approach comes in. Sometimes additional restrictions are added so the script only works on certain pages or under certain conditions. Attackers can ensure their script only works in specific regions or countries, and not all the time. As a result, it's much less noticeable.

So watch for scripts that suddenly start reading form fields when they didn’t before. New outbound connections to domains that look similar to legitimate sites or processors also deserve scrutiny.

Exfiltration looks like normal analytics traffic

Network requests often don't trigger alarms either because they resemble legitimate analytics calls: data gets sent to known endpoints, the servers of trusted third parties. When attackers use domains that closely resemble legitimate sites, detection becomes even harder.

Retroactive work always requires more effort than expected. For the merchant, the customer, and the processor alike.

Traditional security controls look in the wrong place

Attackers first need to find an open window or door to add their code through. That's where the user's browser comes into play.

Precisely because merchants shield their infrastructure well (WAF, IDS) and because transfer protocols are well secured. Many businesses have good practices in place and monitor their servers for back-end errors.

PCI DSS: script monitoring on payment pages

Detection often comes too late. But that's changing. Card issuers know the drill and are increasingly using advanced tools to detect whether payment card data may have been misused. Since March 2025, PCI DSS (requirements 6.4.3 and 11.6.1) requires that scripts on payment pages be monitored. So it's no longer optional, it's mandatory.

Payment processors are also developing systems to track stolen credit card numbers and compare them against suspicious transactions so action can be taken before a payment is accepted.

How to prevent e-skimming: merchant and customer protection

E-skimming is often only discovered when customers themselves report misuse. Too late. Automated runtime monitoring with real-time alerts for changes is a necessity.

How customers can protect themselves from e-skimming

Customers usually know the process and act in good faith based on what they see. Is HTTPS being used? Does the page look familiar? No suspicious warnings?

It's definitely smart to check bank statements and report suspicious transactions immediately. So check those statements regularly: the faster you respond, the quicker action can be taken and worse can be prevented. Or you could use one specific card exclusively for online purchases. If that data gets stolen, the damage stays contained.

But where data ends up, users can't see for themselves. We can't expect customers to review scripts. The ultimate responsibility for e-skimming doesn't lie with the user.

E-skimming prevention for online merchants

Real-time script monitoring is essential. Tools that perform behavioral analysis sound the alarm when scripts behave differently, like an analytics script suddenly reading form data. They also flag new outbound connections to unknown domains or data transfers to regions where you're not active.

CSP violation reports help with this. A properly configured Content Security Policy sends notifications when scripts try to do something they're not allowed to. Those are signals you'd better not ignore.

Audit and limit what runs on payment pages

For merchants, the first step is knowing which scripts run on payment pages. A precautionary measure is ensuring only necessary scripts run there. Anything not strictly needed for payment or fraud prevention: get rid of it.

Real-time script monitoring

Then it's a matter of continuously monitoring for changes and whether scripts get updated. Every change requires merchant attention to determine what the script does exactly and where the data goes.

Not just which scripts are running matters, but also what they do and whether that changes.

Deploy browser security controls: CSP and SRI

E-skimming attacks play out in the browser, so we can use a defensive layer there. CSP and SRI provide that. Granted, they don't solve everything but they do create more visibility.

A strict CSP determines which sources can load scripts and which endpoints they can reach. The script content itself isn't checked, but unwanted data flows get noticed and can be blocked. Start with Content-Security-Policy-Report-Only to test whether everything still works properly.

SRI adds a hash to files: that's how you check whether a script was modified at the source or during transfer. This makes it much harder to spread malicious code through an update or compromised vendor. This works mainly for static scripts. But automatically updating third-party scripts breaks the hash check.

Conclusion

E-skimming will persist as long as browsers trust all JavaScript equally. That doesn't mean you're powerless. The difference between being the next British Airways and catching attacks early comes down to visibility. Start with script inventory, add behavioral monitoring and enforce a strict CSP.

Client-side security starts with knowing what's running on your pages before attackers do. Not a nice-to-have, but a need-to-have.

Frequently Asked Questions About E-Skimming

What is e-skimming?

E-skimming is the online version of skimming at ATMs or point-of-sale terminals. Personal data and payment card details get stolen. In this cyberattack, bad actors inject code that watches what customers type into checkout forms. That data gets used for fraudulent transactions or sold on the dark web.

How does e-skimming work?

Attackers exploit vulnerabilities in third-party scripts. They compromise external vendors and inject their own malicious code into those scripts. They also target weaknesses in e-commerce platforms such as WooCommerce or Magento, or gain access to the merchant’s own environment.

Once attackers manage to inject malicious JavaScript, that code is loaded in the user’s browser. The script captures what the user enters login and checkout forms on online shops. Names, addresses, card numbers, and expiration date, get sent to the attacker’s server, ready to be used for fraudulent purchases or sold on the dark web.

Traditional security controls that run on the merchant’s server often miss these attacks because they take place in the user’s browser. The customer usually notices nothing out of the ordinary because the checkout process and the transaction works as expected.

What is a Magecart attack?

A Magecart attack is a browser-based web skimming attack where malicious JavaScript is injected into a website to steal payment card data or sensitive form inputs directly from the user’s browser during checkout or login. Magecart is less a nickname for a specific group and more an umbrella label for digital skimming groups and techniques. Broadly speaking, they use the same attack vector but rely on different infrastructure and tooling. Magecart attacks are highly sophisticated and can often stay undetected for weeks or months. That's why the consequences can be so far-reaching. British Airways lost data from hundreds of thousands of customers, resulting in a hefty fine. Ticketmaster was also a victim. Customer payment card data was exfiltrated through a compromised chatbot.

What's the difference between skimming and e-skimming?

With skimming, payment card data gets stolen via ATMs or point-of-sale terminals in stores. Physical devices are used: small cameras that record PIN codes or devices that read magnetic strips. With e-skimming, the theft happens entirely digitally. Malicious JavaScript watches along in the browser and registers what the customer enters on a checkout page. The data then gets sent unnoticed to the attackers' servers.

How can customers protect themselves against e-skimming?

Sometimes there are signals that something might be wrong: a domain name that's slightly off from the merchant's, or glitches during payment. But usually, customers can't see that data is being funneled to an illegitimate server. The attack is sneaky and happens invisibly in the background.

You can limit the damage by checking your statements weekly and immediately blocking your card if you spot misuse. You could also use one specific payment card exclusively for online shopping. That makes it easier to intervene when fraud happens.

How can merchants prevent e-skimming?

Merchants need to prioritize client-side security. A first step is getting visibility into the scripts running in users' browsers. Make an inventory and check which scripts are running on checkout pages. Keep only the scripts necessary for payment or fraud prevention.

Install continuous, real-time monitoring with automatic alerts for script changes or unexpected behavior. Beyond that, a strict Content Security Policy (CSP) combined with Subresource Integrity (SRI) makes the difference. CSP limits and controls which sources can load code; SRI adds a cryptographic hash to files to verify scripts haven't been tampered with.

Which websites are vulnerable to e-skimming?

Any website using third-party scripts on login or checkout pages is a potential target. Assume every online shop uses multiple external scripts. And the more scripts, the bigger the risk. A single widely-used compromised script can affect thousands of online shops. Every external script can be exploited by attackers.

Can antivirus software stop e-skimming?

Usually not. E-skimmers run as legitimate JavaScript in the browser, as a part of the website. The antivirus sees it as normal website code, not as malware on your device. The attack happens inside the trusted browser environment where endpoint security has no visibility. That's why e-skimming works so well: it bypasses all traditional security.