Formjacking Explained: How Attackers Steal Card Data on Checkout Pages
Formjacking doesn't require a breach of your server — a single compromised third-party script is enough. Here's the full anatomy and what actually stops the attack.
Formjacking is the hijacking of an HTML form submission by injected JavaScript that forwards the values to an attacker-controlled server. Unlike a classic breach, your origin server often remains untouched — the code runs entirely in the visitor's browser, over the data they are entering.
The attack chain is almost always the same. The attacker compromises a third-party dependency — a tag manager, A/B testing widget, chat script, or npm package — and attaches a listener to the checkout or login form's submit event. On submission the script reads the fields (card number, CVV, email, password) and makes a background POST to a newly registered domain, before or simultaneously with the legitimate submission. The user notices nothing.
Why WAFs don't catch it: a reverse proxy only sees requests to your origin. The exfiltration POST goes to the attacker's domain, not to you — so it never passes through the WAF. File-signature scanners also miss it because the malicious code is not in your files but in a script loaded from a third-party host at runtime.
How ExploitShield detects it: every form submission made by the headless browser is captured at network level via MITM proxy. The destination host is enriched with WHOIS age, RDAP data, IP reputation, and over 500 blocklists. A new exfiltration endpoint — a domain days old — is flagged within its first hours of existence, along with the initiating script, file, and line number.
The practical takeaway for e-commerce teams: audit every third-party script on your checkout and login pages, apply Subresource Integrity where possible, and monitor outbound destinations under real browser execution. That is the only place where formjacking is visible before a customer loses their card data.