Criminals have attached false card readers to ATMs and gas pumps for decades. The device sits on top of the real reader, captures the magnetic stripe, and passes the card through so the transaction completes normally. The victim gets their cash, the machine works, and nothing looks wrong.
Web skimming is the same idea moved into the browser. Instead of a plastic overlay on a card slot, the attacker adds a few lines of JavaScript to a legitimate checkout page. The script reads the payment form as the customer fills it in, sends a copy of the data to an attacker-controlled server, and lets the real purchase go through. The customer receives their order and has no reason to suspect anything until the fraudulent charges start.
Security researchers began tracking groups doing this at scale around 2015 under the name Magecart, a reference to the Magento e-commerce platform whose vulnerable installations supplied many early victims. The name stuck and now covers the whole technique, which has long since spread beyond Magento to custom checkout pages, payment plugins, and the third-party scripts those pages load.
Two Breaches That Defined the Technique
The British Airways breach ran from June to September 2018. Attackers gained access to the airline's systems and modified a JavaScript file served by the site itself, adding a short snippet that read the payment form and posted the contents to a domain named to look plausible in a network log. Roughly 400,000 customers' payment details were exposed. The UK Information Commissioner's Office initially announced an intention to fine British Airways 183 million pounds under GDPR; the final penalty, issued in 2020, was 20 million pounds, at the time the largest the ICO had levied.
The Ticketmaster UK breach the same year showed the second major variant. There, the attackers never touched Ticketmaster's own code. They compromised a customer-support chatbot supplied by a third-party vendor, Inbenta, whose script Ticketmaster had placed on its payment pages. When the vendor's script was modified at the source, every site loading it served the skimmer. The ICO fined Ticketmaster 1.25 million pounds.
The Ticketmaster case is the more instructive of the two, because it generalizes: every third-party script on a payment page runs with full access to the payment form. Analytics tags, chat widgets, A/B testing tools, ad pixels, and tag managers all execute in the same context as the card number field. A typical e-commerce checkout loads dozens of these. Compromising any one of the vendors behind them compromises every checkout page that vendor touches, which is what makes web skimming a supply chain problem rather than a single-site problem.
Why the Padlock Does Not Help
Everything about a skimmed checkout page looks correct to the browser, because everything about it is correct at the layer the browser checks. HTTPS protects data in transit between your browser and the site. A skimmer does not intercept data in transit. It runs inside the page, reading the form before any encryption happens, and it exfiltrates the stolen data over its own perfectly valid HTTPS connection.
The padlock verifies who you are connected to and that the connection is encrypted. It says nothing about what the page's own code does with your data after you type it. A skimmed page passes every check your browser knows how to run.
This is also why the standard anti-phishing advice does not apply. Checking the URL, looking for the real domain, avoiding links in emails: all of it assumes the attacker is impersonating the site. In a web skimming attack the site is real and the attacker is inside it. There is no user-side vigilance that detects 22 lines of hostile JavaScript among the megabytes a modern checkout page loads.
What Stops It on the Site's Side
Because detection by users is not realistic, the defenses that matter are the ones site operators deploy. The main tools:
| Defense | What it does | Limitation |
|---|---|---|
| Content Security Policy | Restricts which domains the page may load scripts from and connect to. A skimmer that cannot reach its exfiltration server steals nothing. | Only as strict as its allowlist; many production policies are too loose to block anything. |
| Subresource Integrity | Pins a third-party script to a hash. If the vendor's file changes, the browser refuses to run it. | Only works for scripts that do not change; most analytics and tag-manager scripts update constantly. |
| Script inventory and tamper detection | Maintains an authorized list of every script on payment pages and alerts on unauthorized changes. | Operational work, not a one-time control; alerts need someone watching them. |
| Hosted payment fields | Renders card inputs inside an iframe served by the payment processor, isolated from the merchant page's scripts. | Attackers have responded by overlaying fake forms on top of the iframe. |
The card industry eventually made two of these mandatory. PCI DSS version 4.0 added requirement 6.4.3, which obliges merchants to inventory, authorize, and integrity-check every script on payment pages, and requirement 11.6.1, which requires a mechanism to detect unauthorized changes to those pages. Both became enforceable in March 2025. We have written before about how Content Security Policy works and what Subresource Integrity can and cannot pin; web skimming is the attack class both were built for.
What You Can Do as a Shopper
Since you cannot see a skimmer, the useful moves all limit what a skimmer can take:
- Use wallet payments where offered. Paying through Apple Pay or Google Pay in the browser sends the merchant a device-specific token and a one-time cryptogram. The page never sees your actual card number, so a skimmer on the page cannot capture it.
- Use virtual card numbers. Several banks and card issuers can generate single-merchant or single-use numbers. A skimmed virtual number is useless anywhere else and easy to burn.
- Prefer credit over debit online. Fraudulent credit charges are the bank's money while disputed; fraudulent debit charges are your checking account while disputed.
- Do not store cards with merchants you rarely use. Stored card data extends your exposure from one transaction to the merchant's entire future breach history.
- Watch statements, not websites. Skimmed card data is typically sold and used weeks later. The signal you can actually observe is the charge you did not make.
None of this prevents the theft. It bounds the damage, which for this attack class is the realistic goal. The prevention has to happen on the merchant's side, and after British Airways, the regulators grade it that way too.