TL;DR:

  • Formjacking attacks inject malicious JavaScript into checkout pages to capture payment card details before they reach your payment processor — customers see a normal transaction, but their card data is silently copied to attackers
  • Magecart is the collective name for threat groups that run these attacks, primarily targeting e-commerce sites using third-party JavaScript, outdated CMS plugins, or compromised supply chain components
  • UK small businesses can significantly reduce exposure through Content Security Policy headers, Subresource Integrity checks, regular third-party script audits, and keeping all platform components updated

If you run an online shop, your payment page is a target. Formjacking — the injection of malicious JavaScript into e-commerce checkout forms to capture card data in real time — has compromised thousands of online retailers globally, from household name brands to small independent shops. The attack is insidious because it’s invisible to customers and business owners alike: transactions complete normally, the card is charged successfully, and the stolen data is simultaneously exfiltrated to attackers.

Understanding how these attacks work and what you can do about them is increasingly important for any UK business that handles card payments on its website.

What Is Magecart?

Magecart is not a single criminal group — it’s a collective term applied to multiple threat actors who run formjacking campaigns against e-commerce sites. The name originally referred to a specific group targeting Magento-based stores (hence “Mage-cart”), but it now covers any organised operation using this attack pattern.

Magecart attacks have hit major organisations — British Airways suffered a high-profile breach in 2018 that exposed 500,000 customers’ card data and resulted in a £20 million ICO fine. Ticketmaster and Newegg have been victims. Small businesses are targeted routinely because they typically have weaker security controls and are harder to monitor than enterprises.

The criminal ecosystem around Magecart is mature. Stolen card data (full track data or card-not-present details) is sold in bulk on dark web markets, with prices ranging from a few pounds for standard cards to £50+ for premium accounts. The attackers monetise the data through fraudulent purchases, balance transfers, or resale.

How Formjacking Works

A formjacking attack follows a consistent pattern:

1. Initial access: Attackers compromise the target website through one of several vectors:

  • Exploiting a vulnerability in an outdated CMS (Magento, WooCommerce, OpenCart), theme, or plugin
  • Compromising a third-party JavaScript library that the site loads (supply chain attack)
  • Stealing administrative credentials through phishing or credential stuffing
  • Exploiting a hosting provider breach that affects multiple sites

2. Script injection: The attacker inserts malicious JavaScript into the site, usually on the checkout page. This can be done by modifying a site’s existing JavaScript files, injecting a new <script> tag into page templates, or compromising a third-party CDN that the site loads.

3. Data capture: The injected script attaches event listeners to payment form fields. When a customer enters their card number, expiry, CVV, and billing address, the script captures each keystroke or the complete form data on submission.

4. Exfiltration: The captured card data is sent to an attacker-controlled server — often disguised as analytics or telemetry traffic to avoid detection. The legitimate transaction also completes normally, so the customer has no indication anything is wrong.

5. Persistence: Sophisticated attackers obfuscate their code, encode it in Base64, store it in database fields rather than files, and set up automatic re-injection if the site is cleaned. Incidents where a site owner “fixed” the breach only for it to return within 24 hours are common.

Why Third-Party Scripts Are the Key Risk

Even if your own website code is secure, you are almost certainly loading JavaScript from third parties: Google Analytics, Facebook Pixel, chat widgets, review widgets, payment form libraries, A/B testing tools. Each of these is a potential vector.

The British Airways breach was executed through a 22-line script injected into Modernizr, a JavaScript library loaded by the site. The attacker didn’t need to compromise BA’s own servers — they compromised one library and waited.

For a small online shop, common third-party scripts that represent supply chain risk include:

  • Analytics (Google Analytics, Hotjar, Clarity)
  • Marketing pixels (Meta, TikTok, Pinterest)
  • Live chat (Intercom, Zendesk, Tidio)
  • Customer reviews (Trustpilot, Yotpo)
  • Address validation or postcode lookup tools

None of these are inherently malicious, but any of them could be compromised upstream.

How to Protect Your Website

1. Keep Your Platform and Plugins Updated

The majority of Magecart attacks on small business sites begin with an unpatched vulnerability in the CMS, a plugin, or a theme. For WooCommerce sites, auto-updates should be enabled for WordPress core, WooCommerce itself, and security plugins. For Shopify stores, the platform handles core updates automatically — your exposure is primarily through third-party Shopify apps.

Check your plugins monthly and remove any that are no longer actively maintained (no updates in the past 12 months is a warning sign).

2. Implement a Content Security Policy

A Content Security Policy (CSP) tells browsers which domains are allowed to load scripts on your site. A properly configured CSP can prevent an injected script from phoning home to an attacker’s server by blocking requests to unauthorised domains.

CSP is implemented as an HTTP response header:

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' https://www.google-analytics.com https://www.googletagmanager.com;
  connect-src 'self' https://www.google-analytics.com;
  img-src 'self' data: https:;
  style-src 'self' 'unsafe-inline';

This example allows scripts only from your own domain and Google’s analytics domains. Any injected script trying to load from an unlisted domain would be blocked.

For WooCommerce sites, implementing CSP requires care because many plugins use inline scripts and dynamic script loading that can conflict with strict policies. Start with Content-Security-Policy-Report-Only mode, which reports violations without blocking, to understand what your existing scripts require before enforcing the policy.

3. Use Subresource Integrity for External Scripts

When you load a JavaScript file from a CDN or external host, Subresource Integrity (SRI) lets you specify a cryptographic hash of the expected file content. The browser checks the loaded file against the hash and refuses to execute it if they don’t match — meaning a compromised CDN file is blocked.

<script 
  src="https://example-cdn.com/jquery-3.7.1.min.js"
  integrity="sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs"
  crossorigin="anonymous">
</script>

SRI hashes are provided by major CDNs including the official jQuery CDN and CDNJS. For scripts you host yourself, generate the hash with:

openssl dgst -sha384 -binary path/to/script.js | openssl base64 -A

SRI only works for scripts loaded with a fixed URL — it cannot protect against scripts injected dynamically at runtime.

4. Audit Third-Party Scripts Regularly

Inventory every external script your checkout page loads. Open your browser’s developer tools on the payment page, go to the Network tab, filter by JS, and list every external domain. For each script:

  • Is it necessary on the payment page specifically? Analytics, marketing pixels, and chat widgets often don’t need to load on the checkout — consider excluding them from payment pages specifically.
  • Is the vendor reputable and does it have a documented security programme?
  • When did the script file last change? Sudden changes to third-party scripts should trigger investigation.

Removing unnecessary scripts from the checkout page reduces your attack surface. A payment page that loads only Stripe.js or your payment provider’s script is significantly harder to compromise via supply chain than one loading six third-party tools.

5. Use a Dedicated Payment Solution

If you process card details on your own website, you bear the full liability for protecting them. The simpler alternative is to use a hosted payment page: Stripe Checkout, PayPal, Klarna’s hosted flow, or SagePay’s redirect. With these, the payment form lives on the payment provider’s domain, not yours. Magecart attackers would need to compromise Stripe’s or PayPal’s infrastructure — a dramatically harder target.

For small businesses, this is often the most effective single change: remove the payment form from your own website entirely and redirect to a hosted provider page.

6. Enable Malware Scanning

Several security services scan your site for injected scripts and alert you to changes. Sucuri SiteCheck, Wordfence (for WordPress), and Malware Bytes for Teams provide ongoing monitoring. For critical retail periods (Black Friday, Christmas), more frequent scans are worthwhile.

UK businesses handling payment card data are subject to PCI DSS (Payment Card Industry Data Security Standard). Under PCI DSS, if customer card data is compromised through your website, you are potentially liable for:

  • Fines from card schemes (Visa, Mastercard) passed through your acquiring bank
  • Card replacement costs for affected customers
  • Forensic investigation costs

Under UK GDPR, payment card data is personal data. A formjacking attack that results in card data exfiltration is a personal data breach that must be reported to the ICO within 72 hours if it’s likely to result in risk to individuals — which a payment card compromise almost always does.

The British Airways breach resulted in a £20 million ICO fine under GDPR. While enforcement at that level is reserved for large organisations, the ICO has issued fines to small businesses for inadequate technical security measures following breaches.

Detecting a Compromise

Signs that your site may have been compromised include:

  • Customer reports of fraudulent charges shortly after purchasing from you
  • Unexpected changes to JavaScript files (check against version control or file integrity monitoring)
  • Your hosting provider or payment processor alerting you to suspicious activity
  • Security scanner reports of unknown scripts on your site

If you suspect a compromise, take the checkout page offline immediately, notify your payment processor and acquiring bank, conduct a thorough file audit, and report to the ICO if customer card data may have been accessed.

References