Formjacking, Magecart, and digital skimming are three layers of one threat. Digital skimming is the outcome: payment or personal data stolen from a site by malicious client-side code. Formjacking is a capture technique that hijacks form inputs. Magecart names the threat-actor groups that run these campaigns. A Magecart group runs a digital-skimming campaign that often uses formjacking.
The terms get swapped freely in headlines, which makes the threat harder to defend. Treat them as one thing and you can end up buying a tool that addresses the wrong layer. This guide separates the outcome, the technique, and the actor, then explains why these attacks slip past server-side controls and how client-side monitoring catches them.
What is digital skimming?
Digital skimming, also called e-skimming or web skimming, is the theft of sensitive data directly from a website using malicious code that runs in the visitor's browser. The classic target is payment card data on a checkout page: card number, expiry, and CVV. Skimmers also harvest login credentials, addresses, and other personal information typed into a form.
The name comes from physical card skimmers attached to ATMs and gas pumps. The digital version gets the same result without hardware. Malicious JavaScript reads the data as the user enters it and sends a copy to an attacker-controlled domain. The transaction still completes normally, so victims and site owners often notice nothing for weeks.
Digital skimming describes the outcome. It says nothing about how the code got there or who put it there. That is where the other two terms come in.
What is formjacking?
Formjacking is a technique for capturing data from web forms. The attacker injects code that hooks into form fields, hijacking or overlaying the inputs so keystrokes are copied as the user types. The legitimate form still works, and the attacker gets a parallel copy of everything entered.
Formjacking is one of the most common ways to carry out digital skimming, but it is not the only one. Skimmers can also:
- Read the DOM directly, scraping field values when the user clicks "pay"
- Hook event listeners on the submit button to grab the form payload
- Intercept network requests (for example, by patching
fetchorXMLHttpRequest) - Overlay a fake payment iframe on top of the real one to capture card data
Formjacking sits inside the broader category of skimming techniques. Every formjacking attack is a skimming attack, but not every skimming attack uses formjacking. For a full breakdown of how formjacking works at the technical level — the injection routes, detection signals, and prevention controls — see our dedicated formjacking guide.
What is Magecart?
Magecart is not a single piece of malware or a single group. It is the umbrella name security researchers gave to the loose ecosystem of threat actors who run digital-skimming campaigns, originally against Magento e-commerce stores (hence "Mage"). RiskIQ and other firms tracked these as numbered groups, each with its own infrastructure, code style, and targeting.
A Magecart operation usually runs through four stages:
- Compromise a script the target loads, often a third-party tag (analytics, chat, A/B testing) or a self-hosted JavaScript file
- Inject a skimmer that activates on checkout or login pages
- Capture the data, frequently using formjacking, and send it to an attacker domain
- Monetize the stolen cards or credentials
Magecart points to who and the campaign, formjacking points to how the data is captured, and digital skimming points to the result. They are not competing terms; they stack.
How the three terms relate: a comparison table
Mapping each term to the layer it describes keeps them straight, alongside a real example and how defenders catch it.
| Term | What it is | Real-world example | How it's detected |
|---|---|---|---|
| Digital skimming | The outcome: payment or PII stolen via malicious client-side code | British Airways 2018, where injected JavaScript skimmed card data and put 429,612 customers at risk | Client-side monitoring that flags data sent to unauthorized domains |
| Formjacking | A technique: hijacking or overlaying form inputs to capture data as it's typed | Skimmers hooking checkout form fields to copy card details on submit | Runtime detection of unexpected listeners and changes on form fields |
| Magecart | The threat-actor groups and the wider e-skimming ecosystem | Magecart groups linked to the British Airways and Ticketmaster breaches | Tracking compromised third-party scripts and known attacker infrastructure |
The relationship in one sentence: a Magecart group (the actor) runs a digital-skimming campaign (the outcome) that often uses formjacking (the technique).
Named real-world incidents
Two 2018 breaches remain the canonical examples, and they show how the layers fit together.
British Airways (2018). Attackers modified JavaScript in the airline's payment flow so card data was copied to an attacker domain while bookings completed normally. The breach put the personal data of 429,612 customers at risk between June and September 2018, and RiskIQ and other researchers linked it to Magecart. The UK's Information Commissioner's Office (ICO) issued a £20 million penalty in October 2020, reduced from an initially proposed £183.39 million, making it one of the most cited regulatory consequences of client-side skimming. (British Airways data breach, Wikipedia; The Register)
Ticketmaster (2018). Ticketmaster initially disclosed that roughly 40,000 UK customers were affected by maliciously injected code on payment pages; the wider incident was later assessed as affecting up to 5% of its global customer base. The skimmer reached Ticketmaster through a compromised third-party supplier script rather than a direct compromise of Ticketmaster's own code. (Magecart, Wikipedia)
That third-party detail matters. You can write perfect first-party code and still ship a skimmer to your users because a vendor script you trust was compromised upstream. Most teams load dozens of third-party scripts on sensitive pages, any one of them is a potential injection point, which is why securing third-party scripts is a control of its own.
Why server-side tools and WAFs miss these attacks
Skimming, formjacking, and Magecart all execute in the browser, after your server has done its job. That property is what makes traditional controls struggle:
- Web application firewalls inspect requests arriving at your origin. A skimmer reads the form field and sends the data straight to an attacker domain, so the malicious traffic never passes through the WAF.
- Server-side scanners check the code on your servers. A compromised third-party tag loads from the vendor's domain at runtime, so it is never in your repository or on your origin to scan.
- Network monitoring sees encrypted HTTPS traffic between the browser and various domains. Exfiltration to an attacker domain often looks like an ordinary analytics beacon.
Verizon's Data Breach Investigations Report has repeatedly flagged web-application attacks and the abuse of third-party code as a leading breach vector, and the response from standards bodies confirms where the gap sits. (Verizon DBIR) PCI DSS 4.0.1 added requirements 6.4.3 and 11.6.1 to address client-side risk directly: organizations must manage and monitor every script on payment pages and detect unauthorized changes to those pages. (PCI Security Standards Council) Those requirements exist because Magecart proved server-side security is not enough.
How client-side monitoring detects skimming in real-time
If the attack runs in the browser, the defense has to see the browser. Client-side monitoring watches every script as it executes for the user, which is the only place a skimmer reveals itself. Effective detection covers:
- Script inventory and change detection. Know every script running on sensitive pages and get alerted the moment one is added, modified, or starts behaving differently.
- Form-field behavior. Flag unexpected listeners attached to inputs, overlays placed on payment fields, and code that reads form values it should not touch.
- Exfiltration monitoring. Detect data sent to domains that are not on your allowlist, which is the signature move of a skimmer.
cside works at this layer. It analyzes scripts and monitors runtime behavior, so it can detect Magecart in real time and catch a tampered third-party script when it changes, not weeks later after the cards are already sold. For payment pages, PCI Shield maps this monitoring to PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1, and the broader client-side security solution covers login and other sensitive flows.
For a wider view of the tooling landscape, see our guide to client-side security tools.
Putting it together
Formjacking, Magecart, and digital skimming are three views of one threat that lives in the browser: the actor, the technique, and the outcome. They do not need three separate products. Defending against all of them takes real-time visibility into what every script does in your users' browsers.
Server-side controls remain necessary, but they are blind to the layer where these attacks operate. The teams that catch skimmers early are the ones watching script behavior at runtime, comparing it to a known-good baseline, and alerting the moment a trusted script starts doing something it never did before.
Book a demo to see how cside detects formjacking, Magecart, and digital skimming on your live pages, or explore the wider tooling landscape in our guide to client-side security tools.
