TL;DR
- E-skimming is a cyber attack where code is injected onto a merchant’s website. Users that visit a payment page have their information stolen by malicious code that watches and “skims” the card details typed in.
- E-skimming captures data before or during payment submission. Information is stolen before it reaches the perimeter of encryption or server security.
- To prevent e-skimming, use a tool like cside that watches third-party script behavior and alerts you of suspicious activity.
- Alternatively, use browser controls like CSP and SRI to manually limit which third party scripts can access payment pages.
What Is E-Skimming?
- E-skimming
- E-skimming (also referred to as “web skimming”) is a cyber attack where a bad actor injects a snippet of code onto a merchant’s website. When a user visits the payment page, the malicious code monitors form inputs to skim card details, which are then sent to an attacker-controlled server for fraudulent use.
For contrast, physical card skimming is when a device is placed on an ATM or payment keypad. An innocent customer uses their card to make a purchase, the device captures the credit card information and PIN entered. The device is built to be invisible going unnoticed by company staff.
Similarly, e-skimming code injections are designed to be invisible. They often stay on payment pages for weeks (and in some cases months) before website owners realize.
What data is targeted in e-skimming attacks
| Data Type | Average Price on the Dark Web |
|---|---|
| U.S. Credit Card | $10 to $100 |
| Gmail Account | $60 |
| Bank Login Credentials | $200 to $1,000 |
| Corporate Login Credentials | $100 to $10,000 |
While e-skimming most commonly refers to credit card information being stolen, web skimming can also broadly refer to attacks that target this information:
- Login credentials (username, email, password)
- Personal information (address, legal name, phone numbers)
Is e-skimming a client-side attack?
Yes. Web skimming, e-skimming, or digital skimming (different names for the same threat vector) are a form of client-side attack.
These are often well-prepared and sophisticated attack with a specialty of certain hacker communities carrying out Magecart attacks.
There are other client-side attacks such as phishing with UI overlays or fake checkout pages.
During web skimming, attackers funnel stolen 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?
Any website that works with third-party scripts, especially when they run on login or checkout pages. Sites built on Magento, WooCommerce, or other low-code platforms are especially vulnerable.
While the platforms themselves are safe and their security teams actively try to patch known vulnerabilities, those platforms are frequently used by non-technical users that are less likely to realize an attack is occurring.
Prevent e-skimming with cside automated client-side security
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. After the payment is submitted data is encrypted and sent to the merchant and card issuer. If the transaction is approved, fulfillment begins.
As soon as the payment is submitted the information is protected by encryption, server controls, API security, and a fortress of other defense processes. Unfortunately, e-skimming captures information before/during the payment submission. The malicious code listens on keystrokes as the user is entering the information.
How hackers inject e-skimming code
When a user visits your website page, their browser loads a mix of code. Some first-party code that your team created (or written by the platform you are using like Shopify or WoooCommerce). But your website also serves third-party code.
For e-commerce sites this includes plugins and third party scripts:
- Analytics tools (like Amplitude)
- Promotional tools (like newsletter email captures)
- Bundle builders
- Ad tracking (Meta, Google)
And many other third party tools that are essential for e-commerce sites.
Third-party scripts are an entry point for web skimming
Each third party script is an entry point for attackers. They can be infiltrated through a variety of methods:
- Expired domains: when an old domain isn’t renewed, attackers can purchase the domain and change the code. If your website is fetching code from that domain, the malicious code will be pulled in.
- Supply chain attacks: If a trusted third-party gets hacked, their script can spread malicious code to your site.
- Through tag managers: If attackers gain access to Google Tag Manager, they can inject code that will go straight to your live website without any review. The activity of that script will be hidden as it is bundled with multiple other scripts.
- Exposed credentials: Stolen credentials may grant attackers internal access to your systems. Instead of trying to break into the vault (your servers) they may choose to inject code on your website.
Individually, established third party tools are safe and carry minimal risk. But modern websites have dozens of third-party scripts. A report from Web Almanac found the median number of third party domains on a website to be 23. And those third-party scripts pull in more scripts (4th party scripts) to help them with data processing.
A chatbot (third party script) might load in a document analysis tool to help customers with support tickets by analyzing their PDFs. You never directly authorized that document analysis tool but it gets served on your site (and accesses sensitive information).
You might start to see the problem: your website ends up with dozens of scripts that can inject code on your site without anyone watching them.
What attackers do with e-skimmed data
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. They can sell that info on the dark web or use the card details themselves for fraud.
How online merchants can prevent e-skimming
1. Monitor third party scripts: what data do they access and where do they send it?
Real-time script monitoring is essential. Tools that watch third party scripts and how they behave will sound an alarm when suspicious activity is identified. For example, if an analytics script suddenly starts reading form data and sending it to a server in Russia you may be facing a client-side attack.
The cside platform monitors third party scripts to see what data they have access to and immediately alerts you if data access changes.
2. Limit what scripts run 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.
3. Use cside for third-party script governance
Many websites default to allowing third party scripts to go straight to the live site. Marketing teams and developers want quick updates for improved functionality. Even companies that do check each script approve them once and rarely review them.
It might seem like enormous manual labor to review every single script that is added, but a tool like cside automatically tracks every new script added and provides an AI-written summary and risk score for you to quickly approve. All scripts are kept in a “live inventory” that privacy compliance or security teams can easily manage.
4. 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.
Why legacy web security doesn’t catch e-skimming
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. Traditional web security tools often have no visibility into this. Even client-side defense tools like Content Security Policy only look at the source of each script. If a trusted source is serving malicious code, content security policies will not catch or block that attack.
