What is web skimming (Magecart, formjacking, e-skimming)?

What web skimming is, in plain terms

A physical card skimmer is a device attached to a card reader that copies the data from your card as you use it. Web skimming is the same idea moved onto a website. Instead of a device on a cash machine, the attacker places a few lines of JavaScript on a page where people enter card details. When a customer fills in the card number, expiry date, security code and billing address, the script reads those values from the form and sends a copy to a server the attacker controls.

The customer still completes the purchase, the merchant still receives the order, and the payment processor sees a normal transaction. That is what makes this kind of attack quiet: nothing breaks, so nothing looks wrong. Stolen cards are typically found out only later, when a card issuer, a payment brand or a security researcher traces a pattern of fraud back to a common merchant.

Names you will see for it

How a skimming attack works

Almost every case follows the same four steps, whichever group is behind it.

1. Get a foothold. The attacker needs a way to change what the browser loads. Common routes are stolen administrator credentials, a vulnerable content management system plugin or library, a compromised server, or a compromise of a third-party service whose script the site already loads. The article on XSS and DOM tampering covers these routes in more detail.
2. Inject the skimmer. The attacker adds a script, or alters an existing one, so that it runs on the page. The injected code is often a small loader that pulls the real skimmer from another domain, which keeps the change to the victim's files tiny.
3. Capture the data. The script listens for the payment form being filled in or submitted, and reads the fields. Some skimmers also capture login details, and some show a fake payment form over the real one.
4. Send it out. The data is sent to the attacker, for example through a hidden image request or a background request to a look-alike domain that resembles an analytics service. Stolen cards are later used or sold.

Skimmers are often written to avoid being noticed: they may run only on checkout pages, skip visitors who look like administrators, hide their code with obfuscation, or wait until the page has finished loading. That is why a quick look at the page in a browser, or an occasional manual review of the source, rarely finds them.

Why server-side security tools usually miss it

Most security controls watch the server, the network or the code in a repository. A skimmer does its work in the customer's browser, after the page has left your servers. Three consequences follow.

• HTTPS does not stop it. The script reads the form fields in the browser, before the data is encrypted for transport. A secure connection protects the data in transit, not against a script that is allowed to run on the page.
• A web application firewall sees only requests to your server. The skimmer's outbound request goes from the customer's browser to the attacker, not through your infrastructure.
• Your own source code may be clean. If the malicious script comes from a third party, or is added by a tag manager or a CDN, a code review of your repository will not show it. What matters is what the browser actually receives.

This gap is the reason PCI DSS added requirements aimed at the browser's view of the payment page: see why the PCI SSC created requirements 6.4.3 and 11.6.1.

Does an iframe or a redirect make a merchant immune?

Sending customers to a payment provider's hosted page, or embedding the provider's payment form in an iframe, greatly reduces the card data that your own systems touch. It is a sound design choice. It does not make the surrounding page irrelevant:

• With a redirect, an attacker who controls your page before the redirect can send customers to a look-alike page instead.
• With an iframe, an attacker who controls the parent page can remove the iframe and put a fake form in its place, or alter how the page behaves around it.

The PCI SSC has dealt with these cases explicitly. How the requirements apply to each way of accepting payments is explained in the article on SAQ A, SAQ A-EP and SAQ D.

How to reduce the risk

No single control stops every skimmer, so organizations combine several. The ones with the best evidence behind them are:

• Load as little script as possible on payment pages. Every script is a place for an attacker to hide. Remove anything that is not needed for taking the payment.
• Keep an inventory and a reason for each script, and approve changes deliberately. See how to build a payment page script inventory.
• Restrict where scripts can load from with a Content Security Policy, and pin external files with Subresource Integrity where that is practical.
• Govern tag managers and third parties as part of your supply chain: third-party JavaScript risk and tag manager risk.
• Patch and harden the site: update plugins and libraries, use multi-factor authentication for administrators, and limit who can publish changes.
• Detect change. Compare what the browser receives against a known-good baseline and alert people when something differs: how to detect client-side tampering.

If you think a page has been skimmed

Treat it as a security incident under your incident response plan. Remove or disable the script, preserve evidence (the page as received, server logs, change history), find and close the way in, and tell your acquirer, payment brands and legal counsel as your contracts and the law require. Your acquirer can tell you what the card brands expect.