Magecart attacks: complete guide and prevention strategy

“I really love online shopping and so far I never had any issue. But recently I was notified of a data breach on you store and my credit card has been abused.”

This is a customer support nightmare. Not only that: your fraud and finance teams are also getting alerts from card issuers and questions from payment providers.

Magecart isn’t about faking login or payment pages.

It’s about the abuse of your real login and checkout pages that customers trust.

That’s Magecart: it’s what happens when your login and checkout become the weakest link in your security controls. Even if your servers, WAF and PCI controls are solid, a few lines of malicious JavaScript in the browser can skim card data and PII for weeks before anyone notices.

This guide shows what Magecart is, how it works, why it is hard to detect and what you can do to prevent it. Use the readiness questionnaire to find where you stand today.

What is a Magecart attack?

A Magecart attack is a browser-based web skimming attack. Malicious JavaScript is injected on an e-commerce site with one purpose: to steal payment card data and personally identifiable information (PII).

It’s something you don’t wish on yourself or your customers. It’s a nightmare for online stores because it abuses the trust of your customers. It causes great damage to online business: financial losses, chargebacks, regulatory fines and serious reputational damage.

PCI DSS and other server-side defenses can be bypassed because these attacks take place in the user’s browser and are therefore largely hidden from your controls. It can take a while before you even notice something is off. Transactions on your side just keep going through as if nothing is wrong. From your perspective, it looks like business as usual. But in the meantime, data is quietly exfiltrated from your customer’s browser to the attacker’s servers.

It is the online version of credit card skimming from ATMs: secret data is copied by hidden devices and later used to spend money elsewhere. So, let’s call it web skimming. When attackers add their malicious JavaScript to an online store, it opens up a lot of opportunities for them. They can see what a user types into payment or login forms and secretly exfiltrate this data to their own systems.

How the term “Magecart” has evolved

Around 2015-2016, security researchers started reporting that Magento-based online stores were being targeted by online card skimming attacks. Typically, JavaScript was injected into checkout pages to steal and exfiltrate payment data and PII. Hence: ‘Magecart’ – ‘Mage’ from Magento and ‘cart’ - short for shopping cart.

Over time, Magecart attacks spread to other platforms and custom e-commerce setups. Any platform with client-side JavaScript and third-party scripts was vulnerable, not just Magento.

From Magento card skimming to Magecart-style attacks everywhere

Even big household brands fell victim to these Magecart attacks: Ticketmaster, British Airways and Newegg. In all these cases, client-side vulnerabilities were cleverly exploited. Third-party providers or popular, widely used JavaScript libraries were infected with just a small amount of well-crafted JavaScript skimming code. Only a limited number of lines were enough to cause significant reputational, legal, and operational damage. In the case of the British Airways Magecart attack for example only 22 lines of code were enough to copy and exfiltrate data of over 300,000 customers to the attacker’s server.

Magecart evolved into an attack style: a label for digital skimming, formjacking, e-skimming, online card skimming and it has become a major threat to online retail platforms.

Magecart is less a nickname for a specific group and more an umbrella label for an ecosystem of digital skimming groups and techniques. Broadly speaking, they use the same attack vector but rely on different infrastructure and tooling.

We can put it this way: Magecart turned the client-side supply chain - CDNs, tag managers, analytics, chat widgets - into an attack surface. And so Magecart has earned its capital letter ‘M’.

How Magecart attacks work

The idea seems simple: copy form data and exfiltrate them to a compromised endpoint. How hard can it be? In reality, these attacks are more subtle and sophisticated. At every moment, the online store needs to behave as expected: no errors, no timeouts.

For the digital skimming to be successful, neither your monitoring systems nor your customers must notice anything out of the ordinary.

Here’s how a typical Magecart attack unfolds in the browser.

Injecting malicious JavaScript into the site

First, the attacker needs a way to run their own JavaScript in the user’s browser, because that is where the attack takes place. They look for vulnerabilities such as outdated or misconfigured plugins or CMS components, or neglected third-party scripts such as a plugin, CDN files, tag manager and so on.

This weak point becomes the attack vector: the attacker adds a couple of lines of their malicious JavaScript to an existing production file or third-party script. The change is tiny, often mixed in with legitimate code, so nothing stands out during a quick review. And because third-party scripts are executed when the online store is loaded in the user’s browser, this injected JavaScript is now running undetected by your usual server-side controls such as HTTPS, WAF, firewalls, PCI detection, traffic and data checks on or behind your server.

Reading payment and form data

Once that is done, the malicious JavaScript accesses the DOM and reads the data the user entered in the form. JavaScript accessing and changing the DOM is normal behavior in modern web development. It’s how JavaScript makes pages dynamic without reloading the full HTML-document. Many frameworks like React or Svelte rely on the fact that JavaScript can manipulate the DOM.

The digital skimmer now focuses on specific fields in the payment or login form: card number, expiry date, CVV, name, address and so on. It copies these values without changing the form or the user flow in any visible way. Remaining undetected is critical: any disruption of the payment process, error message, timeout or long delay might alert the customer something is wrong.

Exfiltrating the data to the attacker’s server

Once the data is captured, the next step is to transfer it undetected to a server controlled by the attacker. Most of the time, the trigger for the exfiltration is the user clicking the ‘pay’/’submit’ button. At that moment, the script assembles the payload (raw or encoded) with card details, PII, and often details for context such as timestamps or URLs.

Typical exfiltration techniques include ‘fetch’, ‘XMLHttpRequest for old code, hidden image requests and navigator.sendBeacon(). TLS/HTTPS won’t stop the exfiltration because it looks like a legitimate https-request, with a very small payload. Attackers often use domains that look very similar to the legitimate hostnames used by online stores, CDNs or analytics so they don’t raise suspicion. If the exfiltration request fails, the code simply catches the error and will not run. But the legitimate transaction will go through.

Keeping the store running and fulfilment firing

For the Magecart attack to be effective, transactions must keep flowing. The skimmer exfiltrates a copy of the data, but the payment form is also submitted to your backend and payment gateway. Orders are created, payments are authorized and your fulfilment systems get to work. From your side, there are no warning signs: orders are logged and your server-side monitoring systems show normal request and response patterns because the attack happened in the browser, before the data reached your security controls.

Everything looks fine in your metrics and PCI reports. The blind spot in this case is the browser of the user and its outbound connections.

Customers do not complain about missing orders. At least, not right away and not directly. For them, everything worked as expected. The damage will only show up later, when banking or credit card issuers start detecting fraud in those payment cards.

Why Magecart attacks are hard to detect

Now that we've seen how a Magecart attack works in the browser, it’s fair to ask: Why don’t our defenses catch this? We have WAF rules, SIEM dashboards and PCI controls. Yet these security layers still have a blind spot for client-side, browser-based attacks like Magecart.

Detection blindness in WAF, SIEM and PCI

Most security tools are designed to protect server-side activity, not the browser of users. A WAF inspects traffic to your applications, but it doesn’t see what the browser sends directly to other domains. A SIEM shows server and infrastructure logs, but it doesn’t record extra outbound calls from the browser to malicious endpoints.

As for PCI DSS controls, they make sure cardholder data is handled securely on your systems, but they don’t check the DOM or the JavaScript that executes in the user’s browser. Apart from that, Magecart operates before data even reaches your backend.

As a result, suspicious browser-side requests that exfiltrate card data or PII straight to an attacker-controlled domain never even show up in your WAF, SIEM or PCI reporting and will never trigger an alert.

Third-party scripts: governance and visibility

Third-party scripts have become essential building blocks of modern online stores. Their job is to add interactivity: chatbots, analytics, A/B testing, marketing tags, social media widgets and so on. It’s not unusual for a single page to load 20 or 30 third-party scripts.

Full visibility into these scripts is a huge challenge. What scripts are running? Are they allowed to run on a checkout form or login page? Who’s keeping track of their behavior and changes over time? All very basic questions that many organizations struggle with when nobody fully owns the client-side supply chain.

Web developers have limited control over these scripts, because they are managed and hosted by external vendors. When ownership changes or staff is laid off, third-party scripts or JavaScript libraries may no longer be updated and a vulnerability in any of those third-party scripts can become a security risk.

This is precisely the entry point Magecart attacks exploit. Compromise one widely used third-party script or library, and you can turn it into a large-scale supply chain attack across every site that uses it.

A client-side problem needs client-side defense

This is the core issue with Magecart: most businesses have no real visibility into what happens in the browser. Server-side dashboards show server metrics, measure latency, track for errors and monitor on throughput, but they don’t show the activity you need to discover Magecart.

They don’t show what domains the browser is sending requests to during checkout, even when those are cross-origin calls (CORS). They don’t alert when a new outbound domain shows up on a payment form. And they don’t send a warning on a Content Security Policy violation (connect-src) when a script is trying to exfiltrate data to an unexpected endpoint.

In short: most organizations simply don’t have real time, client-side monitoring with alerts on CSP connect-src violations or unknown outbound domains on checkout and login pages. Magecart is a client-side problem and without client-side visibility your defenses are down.

Fraud is only discovered later, much later

Late fraud discovery is another side effect of Magecart. Because transactions go through and everything looks normal for everyone involved, Magecart can stay under the radar for a long time and cause damage at scale.

The fraud only surfaces when the compromised card data is getting abused. And it’s not the online store, but banks and credit card issuers that see this first. They notice unusual patterns in transactions and start an investigation. By that time, digital skimming has often been going on for weeks or even months.

Only after the investigation, the spotlight falls on the online store, when banks or card issuers can prove that a high number of compromised cards were all used in the same online store. By then, it’s no longer an isolated technical incident, but something much larger and scarier: a full-blown data breach with legal, financial, operational and reputational consequences.

How attackers gain access to website scripts

Attackers are scanning for weak spots in your web stack: places where scripts can be edited and skimming code can slip in. To defend your site and build an effective threat model, you need to focus on some common entry points for Magecart attacks.

Your own platform code

Your own CMS or e-commerce platform is a direct attack surface. Platforms such as Magento, WooCommerce, Shopify-apps and custom checkout-code need regular scrutiny. Typical weak points are outdated plugins and extensions, or insecure edits to templates or JavaScript files. Admin-accounts need extra protection: if an attacker can log in as administrator, script changes are easy.

If your online store is running an outdated payment or tracking-plugin in Magento or WooCommerce, digital skimming is only one step away. If attackers succeed in modifying the plugin files or abuse an admin account, they only need to edit one single JavaScript-file on the checkout page to add their skimmer.

The third-party ecosystem

This includes any entry via <script src> or a tag manager: CDN-libraries, A/B testing or analytics for your marketing team, chat/support widget for customer support and so on. These scripts are managed and hosted by external vendors or injected via tag managers that can run code on most pages. It only takes one compromised third-party script or abused tag manager account to spread skimmer code to all sites and pages where this code is used.

Sometimes Google Tag Manager (GTM)-account and external chat widget are running across the entire site, including checkout. If GTM is taken over and an extra tag with skimmer JavaScript code is added, every checkout form on every site that uses the container is now running Magecart code. When popular but unmaintained JavaScript libraries and unpatched legacy code is targeted, a single incident turns into a widespread supply-chain attack.

Considering the consequences, that’s why these assets need your scrutiny before attackers zoom in on them: jQuery-versions, legacy front-end bundles, custom “util.js”, unpatched libraries, publicly available bundles, misconfigurations in build or host pipeline and JavaScript-injections in static assets that run across all pages of your site.

How to prevent Magecart attacks

The core principles of Magecart prevention are straightforward: keep your checkout flow as clean and minimal as possible, keep control of scripts that run there and add browser-side controls and continuous 24/7 monitoring. The following logical steps will help you to implement prevention measures to reduce your exposure to Magecart.

Only run necessary scripts on login and checkout

For login and checkout, every extra script adds risk. These pages should load only basic UX and what is strictly necessary for authentication and payment. Without hesitation, remove marketing, analytics, chat widgets and so on from login and checkout. Preferably, isolate checkout and use a minimalistic template or even a separate subdomain with only necessary third-party input. In doing so, you limit your attack surface and the opportunities for Magecart code to hide its tracks. Also, you’ll have a much easier time to clean up if something goes wrong.

Third-party governance: control your scripts

The first step is to limit third-party scripts from going rogue is to know what actually runs on your site. Create a script-inventory to get a clear view of what scripts run where, and what they are allowed to do. Login and checkout should definitely be no go zones for third-party scripts, unless there’s a clear reason. This inventory is the foundation for your CSP.

Finally, define a change management process to specify who is allowed to modify scripts and tag manager containers. You can also require previews and approval before changes go live. In parallel, apply strict vendor governance and make script security and incident handling part of contracts and onboarding with external providers.

Use browser controls: CSP and SRI

A Content Security Policy (CSP) helps you define where scripts are allowed to load from (script-src) and where the browser is allowed to send data (connect-src).

script-src should be restricted to trusted domains and connect-src should allow only the endpoints needed for checkout rather than allowing every destination.

Enabling a CSP also helps reporting on policy violations, especially on login and checkout. Unexpected script injection and exfiltration attempts will be revealed. For static third-party libraries, use Subresource Integrity (SRI) to harden integrity but treat it as one layer in your defense, not as the silver bullet solution.

Add client-side visibility and monitoring

With Magecart, you need eyes in the browser. Continuous, 24/7 automated client-side monitoring with Magecart scanners, will reveal what scripts are running and the outbound connections of the browser during checkout. So, look for tooling that maps all the scripts on your site and that collects and analyses CSP reports. It should detect and alert on transfers to unauthorized outbound domains and track the changes in critical scripts and bundles.

These measures will make it much harder for a digital skimmer to steal data and remain undetected for weeks or months.

Magecart readiness quick self-assessment

Biggest Magecart attacks in recent history

Ticketmaster (2018): chatbot on payment page

For Ticketmaster, a third-party chatbot turned into a damaging attack vector in 2018. How did that happen? A custom chatbot from supplier Inbenta Technologies was added as a script to the payment page. Attackers injected skimming code into the chatbot’s JavaScript on Inbenta’s infrastructure. Every time the checkout page loaded, the skimmer code ran in the browser. The skimmer scraped data that should have been protected: names, addresses, login and payment card data and so on. The attack went on for four months before it was discovered. About 9,4 million customers were notified that their data might have been compromised.

In 2020, the UK Information Commissioners Office (ICO) imposed a fine of BPS 1,25 million for failure to protect customer data. Ticketmaster filed an appeal that was dropped later. A confidential class action settlement with over 1000 claimants was reached years later, in 2022.

British Airways (2018): 22-line skimmer on checkout

A digital skimmer managed to steal the payment data and PII of about 400.000 customers and staff booking travel on the British Airways site or mobile app. The attack started when attackers used the Citrix remote access gateway to gain access to BA’s environment with compromised credentials of a third-party staff member.

Only 22 lines of JavaScript skimming code were injected in a JavaScript library used on the British Airways payment page. When users filled out the form, a copy of that data was sent to a look-alike domain, baways.com, controlled by the attackers. It was designed to blend in with the brand and the normal payment flow.

The attack lasted about 16 days; the consequences ran for years. Initially, the ICO announced a fine of £183 million under GDPR, and later lowered that to £20 million. In 2021, a group action led to confidential settlements providing compensations for claimants.

Newegg (2019): compromised custom checkout script

Another data breach that made headlines targeted US electronics store Newegg in August and September 2018. It took over a month before the attack was discovered, and, by then, large number of customers had their data skimmed: credit cards numbers, expirations dates, CVV codes and PII. In this case, the breach wasn’t caused by a compromised third-party library, but by injected JavaScript on Newegg’s own checkout page.

Whether the attackers got in using stolen admin credentials or a server-side vulnerability is not clear. What is known is that they gained write access to the payment server and added a small skimmer script to the payment button. When the customer clicked the payment button, the code copied the data in the billing form fields and sent it via HTTPS to a fake but legitimate-looking analytics domain, neweggstats.com.

These cases show how only a few lines of skimmer code can cause damage at scale and lead to lengthy, costly litigation and settlements, not to mention the reputational damage that is hard to shake off.

Conclusion

In Magecart attacks, server-side defenses and PCI controls see nothing unusual, while the real breach is happening in the browser. Skimmers can stay under the radar for weeks and even months. The real pain comes later, when card issuers and banks start flagging fraud, followed by legal, reputational, financial and organizational damage.

This is exactly why Magecart deserves to be on your risk radar. The moment a skimmer tries to siphon data from your checkout, you should know about it. Not months after the fact.

Use the quick self-assessment questionnaire to check where you stand today. Then review the scripts that run on your login and checkout pages. Take the time to tighten your script-src and connect-src policies and to add client-side monitoring. The sooner you shine a light on the browser blind spot, the harder it becomes for a few lines of JavaScript to turn into a data breach.