# What Is Magecart? Client-Side Skimming and How to Detect It Source: PageCrawl.io Blog URL: https://pagecrawl.io/blog/what-is-magecart-client-side-monitoring --- A mid-size retailer ran a routine quarter. Sales were steady, the checkout flow worked, and not a single server alarm fired. Then the card networks called: hundreds of customers who had bought from the site in the previous six weeks were reporting fraud, and the common point of purchase traced back to one place. The retailer's servers were clean and their database was untouched. The breach lived entirely in the customer's browser, in a few dozen characters of JavaScript that quietly copied every card number typed into the payment form and shipped it to a domain the attacker controlled. The checkout page looked and behaved exactly as it always had. That is Magecart. This attack class has hit British Airways, Ticketmaster, Newegg, and thousands of smaller merchants who never made the news. It does not require breaching a database or cracking a password. It requires getting one script onto your payment page, and that script can arrive through a third party you have never audited. Because the skimmer runs in the browser and never touches your origin server, the tools most teams rely on (file-integrity scanners, web application firewalls, server logs) are looking in the wrong place. This guide explains what Magecart is, how attackers inject card-skimming code, why it is so hard to spot, how PCI DSS 4.0 now requires you to watch for it, and how monitoring the scripts and integrity of your pages catches tampering before your customers do. ### What is Magecart? Magecart is an umbrella term for client-side web skimming: malicious JavaScript injected into a checkout or payment page that harvests card numbers, CVVs, names, and addresses as customers type them, then sends that data to an attacker-controlled server. The code runs in the visitor's browser, not on your server, which is what makes it both effective and hard to detect. The name originally referred to attacks against Magento storefronts, but the technique is platform-agnostic now. It works against any site that collects payment or sensitive data in a form, whether that is a custom checkout, a SaaS billing page, a donation form, or a login screen. Researchers track dozens of distinct threat groups under the Magecart label, each with their own infrastructure and tooling, so "Magecart" describes a category of attack rather than a single gang. #### What client-side skimming actually steals A skimmer hooks into the form fields a customer interacts with and reads the values directly, before they are encrypted and submitted to your payment processor. Because it operates at the keystroke or form-submit level inside the browser, it sees the data in the clear: the full card number, expiry, CVV, cardholder name, billing address, email, and phone. Some skimmers also grab login credentials or stored-card details from account pages. The data is base64-encoded or lightly obfuscated and beaconed out to an exfiltration domain, often one whose name mimics a real analytics or CDN provider so it blends into network traffic. #### Why server-side defenses miss it The defining trait of a Magecart attack is that nothing changes on your origin server in a way your usual tooling notices. The malicious code can be served from a compromised third-party script, injected through a tag manager, or planted in a JavaScript file your build pipeline never rebuilt. File-integrity monitoring, a WAF, and access-log review all assume the threat touches infrastructure you control. A browser-side skimmer routes around every one of them. The only place the attack is fully visible is the page as it renders in a real browser, after all scripts have executed. ### How do attackers inject card-skimming JavaScript? Attackers get skimming code onto a payment page through two broad routes: compromising a third-party script the page already loads (the supply-chain path), or directly altering your own pages and files after gaining some level of access. Both end with malicious JavaScript executing in the customer's browser, and the supply-chain route is by far the more common because it scales. A single payment page typically loads code from many origins: your own checkout script, the payment processor's library, analytics, a tag manager, session-replay tools, A/B testing, chat widgets, and fraud-scoring scripts. Every one is an entry point. If an attacker compromises any provider in that chain, their script gets weaponized against your customers without anyone touching your servers. This is why client-side risk is fundamentally a supply-chain problem, and why it overlaps with the package-level risk covered in our guide on [supply-chain monitoring for package releases](/blog/pypi-npm-package-release-supply-chain-monitoring). #### The supply-chain route The most damaging Magecart incidents have come through trusted third parties. An attacker compromises a widely embedded script (an analytics provider, a chat widget, a marketing pixel), modifies the file at its source, and every site that loads that script inherits the skimmer instantly. The merchant did nothing wrong on their own servers and gets breached anyway. The British Airways attack injected just 22 lines of code; the Ticketmaster breach came through a compromised third-party chat support script. From the merchant's side, the page is loading exactly the resources it always did, from exactly the domains it always trusted. Only the contents of one of those resources changed. #### Direct compromise of your own pages The second route is more conventional: an attacker gains access through a stolen admin credential, an unpatched CMS or plugin, an exposed deployment pipeline, or a misconfigured storage bucket, and edits your page templates or JavaScript bundles directly. They add a `