Formjacking and Magecart: E-commerce Card Skimming

If your small business sells anything through an online store, there’s a specific attack worth knowing by name: formjacking, often carried out through a family of malware called Magecart. It doesn’t need to breach your server or steal a database — it just needs to quietly rewrite what happens when a customer types their card number into your checkout page, and most store owners never notice until the chargebacks start.

What Formjacking Actually Is

Formjacking is the injection of malicious JavaScript into a website’s checkout or payment page so that it silently copies card numbers, expiration dates, CVVs, and billing details as the customer types them — then sends that data to an attacker-controlled server, usually while the legitimate transaction still goes through normally. The customer sees nothing wrong. Their order ships. The business has no idea anything happened until stolen cards start showing up in fraud reports weeks or months later.

Where Magecart Fits In

Magecart is the umbrella name for a family of criminal groups and the skimming code they use, first identified targeting Magento stores years ago but now found across WooCommerce, Shopify (via compromised apps), and custom checkout pages on virtually any platform. The injected script is often just a few lines, obfuscated to look like analytics or advertising code, which is exactly why it tends to go unnoticed during casual code review — it’s designed to blend in with the dozens of legitimate third-party scripts already running on a typical e-commerce page.

How the Malicious Script Gets In

The injection point is rarely your core platform itself — it’s almost always a dependency. Common entry paths: a vulnerable or outdated plugin or theme with a known exploit, a compromised admin account with weak or reused credentials, a cross-site scripting (XSS) vulnerability in custom code, or a supply-chain compromise where a third-party script you load from a CDN (a chat widget, an analytics tool, an ad script) gets compromised at the source and starts serving malicious code to every site that embeds it — including yours, without you changing a single line of your own code.

Why MFA and a Clean Server Don’t Stop This

This is the detail that trips up a lot of small business owners: formjacking doesn’t require stealing admin credentials or breaching your database, so your normal defenses — strong admin passwords, MFA on your WordPress or Shopify login, server hardening — don’t directly prevent it. The attack lives in the browser, on the customer’s side, in code your site is serving. You can have excellent server security and still be actively skimming cards right now if a single script on your checkout page has been tampered with.

The New PCI DSS Requirement That Makes This Mandatory to Address

As of March 31, 2025, PCI DSS v4.0.1 made two requirements specifically about this threat mandatory rather than optional for any business that takes card payments: Requirement 6.4.3 requires maintaining an inventory of every script running on your payment pages — including third-party scripts — with documentation of each script’s purpose, authorization, and what data it can access. Requirement 11.6.1 requires a mechanism that alerts you to unauthorized changes to scripts or HTTP headers on payment pages, checked at least weekly or on a documented risk-based schedule. If you haven’t looked at this since your last PCI self-assessment, it’s worth checking now — these aren’t best practices anymore, they’re compliance requirements.

Practical Defenses for a Small Online Store

Start with a Content Security Policy (CSP) header that explicitly whitelists which domains are allowed to load scripts on your checkout page — this alone blocks most unauthorized script injection outright, since a script from an unlisted domain simply won’t execute. Add Subresource Integrity (SRI) tags to the third-party scripts you do load, which makes the browser verify the script hasn’t been tampered with before running it. Together, CSP and SRI cover the two most common formjacking vectors without requiring custom monitoring software.

Script Inventory and Change Monitoring

Beyond the technical controls, do a manual audit: list every script that loads on your checkout page right now, including ones added by plugins you may have forgotten about, and confirm you still need each one. A surprising number of small stores are running analytics tools, chat widgets, or marketing pixels that nobody currently uses but nobody removed either — each one is an additional attack surface. Several third-party monitoring services and some web application firewalls now offer change-detection specifically for payment-page scripts, flagging you the moment something on that page is modified.

Keep Plugins and Themes Current — Especially on Checkout-Adjacent Code

Outdated WooCommerce plugins, payment gateway integrations, and themes are the single most common entry point for the initial compromise that leads to a formjacking injection. Set a recurring reminder to check for updates weekly rather than whenever you happen to log into the admin panel, and remove plugins you’re no longer actively using rather than leaving them installed and unpatched.

What to Do If You Suspect an Active Skim

If you see unexplained chargebacks clustering around a specific time window, or a payment processor flags unusual fraud patterns tied to your store, treat it as a possible active formjacking incident: pull up your checkout page’s source and compare the loaded scripts against your inventory, check your web server and CDN logs for unexpected outbound connections from the checkout page, and consider taking the checkout page offline temporarily while you investigate rather than leaving a live skimmer running while you figure out what happened. Notify your payment processor as soon as you suspect an active skim — most have their own fraud teams who can help flag affected transactions and may be able to tell you which cards were used during the suspected window, which helps you scope how many customers need notification.

Notifying Affected Customers

If you confirm cards were skimmed, most states have breach notification laws that require informing affected customers within a specific timeframe, and your payment processor’s own merchant agreement likely has separate reporting obligations as well. Don’t wait for certainty before starting that process — notify as soon as you have reasonable grounds to believe a skim occurred, since the clock on most notification deadlines starts from discovery, not from full confirmation. A small business that handles this transparently and quickly tends to retain far more customer trust than one that goes quiet and lets customers find out from their bank instead.

Bottom Line

Formjacking and Magecart-style attacks target the browser side of your checkout page, not your server, which means the usual password and MFA defenses won’t catch them — a Content Security Policy, Subresource Integrity tags, and an honest inventory of every script touching your payment page are what actually close this gap, and as of 2025 the first two pieces of that inventory-and-monitoring discipline are a PCI DSS requirement, not just good practice.