Magecart-style checkout skimmers: how script injections steal card data without tripping any alarms

A store owner runs PCI-compliant checkout, has an SSL certificate, uses a reputable payment gateway, and never touches raw card numbers because the processor handles all of that. By every standard measure, the store is secure. And yet for four months, a script quietly sitting in the checkout page has been copying every card number typed into the form and sending it to a server in another country. Nothing broke. No error logged. No customer complained, because their orders still went through fine. The only thing wrong was that their card got used fraudulently somewhere else, weeks later, with no obvious connection back to this store.

This is a Magecart attack, and it has been quietly draining ecommerce stores for years. The name comes from Magento, where the technique was first widely documented, but it has nothing to do with any one platform. It works on Shopify, WooCommerce, BigCommerce, or any store that loads third-party JavaScript on its checkout page, which is nearly all of them.

How a checkout script injection actually works

A Magecart attack ecommerce incident almost never starts with someone breaking into your admin panel. It starts with a third-party script you already trust. Stores routinely load code from analytics tools, chat widgets, review plugins, ad pixels, upsell apps, and personalization tools, often a dozen or more scripts running on the checkout page alone.

Attackers don't need to compromise your store directly. They compromise one of the vendors whose script you've embedded, or they exploit an unpatched app, or they find a forgotten script tag left over from a tool you stopped using. Once they control that script, they inject a few lines of code that do one simple thing: listen for keystrokes in the card number, expiry, and CVV fields, then quietly send that data to a server the attacker controls, all before the form is even submitted.

The card payment itself still goes through normally. Your gateway processes it, the order confirms, the customer gets their receipt. The skimmer doesn't interfere with the transaction at all. It just makes a copy on the way past. That's what makes checkout script injection so hard to catch: everything downstream of the keystroke looks completely normal.

Why PCI compliance and SSL don't catch this

Most merchants assume that once they're PCI compliant, card data theft is someone else's problem. PCI DSS does meaningfully reduce risk, particularly around how card data is stored and transmitted on your server. But a Magecart skimmer operates entirely client-side, in the customer's browser, intercepting data before it's ever submitted to your server or your payment processor. PCI compliance governs what you do with card data once it reaches your systems; it was never designed to monitor what third-party JavaScript does inside the page itself.

SSL certificates run into the same blind spot. Encryption protects data in transit between the browser and your server. It does nothing to stop a script running inside that encrypted page from reading form fields before encryption happens. A site can have a perfectly valid certificate, a padlock icon, and a PCI attestation on file, and still be actively skimming cards. For a deeper look at how SSL issues get misread as security assurance, see the SSL certificate that expired overnight.

This is also distinct from server-side vulnerabilities like SQL injection or admin credential theft. Card skimming Shopify and WooCommerce incidents typically exploit the supply chain of scripts running in the browser, not a weakness in the platform's core code.

Third-party scripts are the real attack surface

Every app you install, every tracking pixel you add, every chat widget you embed is a form of third-party script security risk, because each one is code you didn't write, running with full access to the page your customers use to pay you. Most stores have no inventory of exactly which scripts are loading on checkout, let alone what each one does.

This problem compounds over time. Apps get uninstalled but leave scripts behind. Vendors get acquired and change their infrastructure. A review widget installed two years ago by an employee who no longer works there is still quietly loading code from a domain nobody checks anymore. This is the same pattern covered in orphaned app code: old scripts don't just cause bugs, they stay live as unmonitored attack surface.

Shopify and BigCommerce limit some of this risk by giving merchants less direct control over checkout page code on their hosted checkout, which is one reason Magecart incidents have historically concentrated more heavily on self-hosted platforms like Magento and WooCommerce, where store owners can edit checkout templates directly and third-party plugins have deeper access. That said, Shopify Scripts, checkout extensions, and apps with checkout-page access have all been documented as potential injection points in security research from the broader ecommerce security community, so no platform is categorically immune.

What monitoring actually catches a skimmer versus what doesn't

The uncomfortable truth is that most of the checks merchants already run, uptime monitoring, page speed tests, order volume dashboards, won't flag a Magecart infection at all. The checkout page loads fast, orders complete, revenue looks normal. You'd have to be specifically looking at checkout page integrity to notice anything.

What does help is treating the checkout page's script environment as something to monitor continuously, not something you configure once and forget. That includes watching for new or changed scripts appearing on checkout pages, unexpected outbound connections to unfamiliar domains, and unauthorized changes to checkout templates or theme files. Security researchers and vendors in this space generally recommend Content Security Policy headers to restrict which domains checkout pages are allowed to load scripts from at all, since a tightly scoped CSP can block an injected script from ever executing, even if it gets inserted into the page.

This is part of why Cassian™ includes security scanning (Cassian Shield) alongside uptime and checkout monitoring: a skimmer doesn't announce itself with downtime or errors, so catching it means watching for change on the checkout page itself, not just watching whether the checkout page works. The Cassian Score™ reflects this broader view of store health, pulling together signals that a single uptime check would miss entirely. Cassian detects and alerts; it's not a replacement for a security audit or PCI assessment, but it closes a gap that compliance checklists and uptime pingers both leave open. For more on where uptime tools stop being sufficient, see uptime monitors, status pages, and pingers.

What you can do this week

You don't need a security team to reduce your exposure meaningfully. Start by auditing every script currently loading on your checkout page, including ones added by apps you installed long ago and forgot about. If you can't explain why a script is there, that's reason enough to remove it.

Next, check whether your platform and theme support Content Security Policy headers, and if so, scope them tightly to only the domains you actually need. Review your app list for anything inactive or unused, since uninstalled apps sometimes leave scripts behind, a problem covered in more detail in the orphaned app code piece linked above. Finally, treat checkout page changes as something worth knowing about in near real time, not something you discover during a quarterly review.

The quiet failures are the costly ones

Magecart attacks succeed because they're boring by design. No downtime, no error pages, no angry customers at the moment of purchase, just a slow, silent leak that surfaces weeks later as chargebacks, reputational damage, and in some cases regulatory exposure. The same instinct that makes store owners check for broken links, slow pages, or stalled orders needs to extend to checkout page integrity, because that's exactly the layer attackers are counting on nobody watching.