Magecart Attacks: How Card Skimming Works and How to Stop It
Magecart is the name given to a style of attack rather than a single group: injecting malicious JavaScript into a checkout page to copy card details as customers type them. The shop keeps working. The order completes. The customer gets their goods. And their card is skimmed on the way through.
It is the digital equivalent of a card skimmer on a petrol pump, and it is difficult to spot precisely because nothing appears to be broken.
How the attack works
The attacker needs to get a few lines of JavaScript onto your checkout page. Once there, the script watches the payment form and sends the field contents to a server they control, usually as the customer types rather than on submit, so it captures details even if the order is abandoned.
The theft happens in the browser, before the data ever reaches your payment gateway.
Click for full sized image
Because it runs in the browser, it sees the card number in plain text before any encryption your site performs. Server side security does not help. Neither does PCI compliance of your payment gateway, because the theft happens before the data reaches the gateway.
How the script gets there
Four routes, and only the first is what most people picture.
Direct compromise. An outdated CMS, a vulnerable plugin, a weak admin password, or a stolen FTP credential. The attacker edits a template or injects into the database.
A compromised third party script. This is the one that catches careful sites. Your checkout loads a live chat widget, an analytics tag, a review widget or an A/B testing tool from someone else’s server. If that provider is breached, your checkout now runs their attacker’s code. You did nothing wrong and you are still compromised.
A compromised extension. A plugin author’s account is taken over and a malicious update is pushed. You install it in good faith.
Hosting or supply chain. Shared hosting where another account is compromised, or a CDN account taken over.
Why it goes unnoticed
There is no error, no downtime, and no change your customers can see. The script is usually obfuscated, often loaded from a domain that looks plausible, and increasingly only activates on the checkout URL and only for a percentage of visitors, which defeats casual testing.
Most victims find out from their payment processor or their bank, weeks or months later, after fraud is traced back to cards that all have one merchant in common.
What actually reduces the risk
Audit what your checkout loads. Open your checkout, open the browser’s network tab, and look at every external domain being contacted. Most shops are surprised. Anything you cannot justify should not be on the page that handles card details. Marketing tags in particular have a habit of accumulating.
Use a hosted or iframed payment form. If the card fields live in an iframe served by your payment provider, script on your page cannot read them. This is the single most effective control available, and it is why gateway-hosted fields are worth the slight loss of styling control.
Add a Content Security Policy. A CSP lets you declare which domains may serve scripts. An injected script pointing at an attacker’s domain simply does not run. Start in report-only mode so you can see what would break before enforcing.
Use Subresource Integrity where you can. An SRI hash on an external script means the browser refuses to run it if the file changes. It does not help for scripts that legitimately change often, but it is ideal for pinned library versions.
Keep the platform and extensions current. Unglamorous, and still the most common entry point. That includes removing extensions you no longer use rather than leaving them disabled.
Lock down admin access. Two factor authentication on every account, and delete logins for people who have left. Most direct compromises start with a credential, not an exploit.
Monitor for file changes. Something that alerts you when template or theme files change unexpectedly will catch a direct injection quickly.
If you think you have been hit
- Take the checkout offline. Every additional order is another skimmed card. This is worth the lost revenue.
- Tell your payment provider and your bank immediately. They have processes for this and may already have suspicions.
- Preserve evidence before cleaning. Take a full backup of files and database first. Cleaning destroys the forensic trail you may need.
- Find the entry point. Removing the script without finding how it arrived means it comes back within days.
- Rotate every credential. Admin, FTP, SSH, database, API keys, payment gateway keys.
- Consider your notification obligations. Under UK GDPR a personal data breach must be reported to the ICO within 72 hours where there is a risk to individuals, and affected customers told where the risk is high. Take proper advice rather than guessing.
A note on CubeCart specifically
Most Magecart coverage focuses on Magento, because early campaigns targeted it heavily and the name stuck. The technique is platform agnostic. Any shop that renders its own card fields in the browser can be skimmed.
Recent CubeCart releases have hardened several relevant areas, including template injection routes and an allowlist HTML sanitiser on product fields. Being on the current release matters here, because template injection is exactly the mechanism a Magecart script would use.
The short version
Reduce what your checkout loads, move card fields into an iframe your provider controls, add a CSP, keep everything patched, and put two factor authentication on your admin accounts. None of it is exotic, and together it removes most of the routes in. Our wider guide to the website security measures that actually matter covers the rest of the ground.
If you host your shop with us and want a review of what your checkout is loading, or help putting a Content Security Policy in place without breaking anything, get in touch.
