Most articles about formjacking describe the attack in the context of e-commerce checkout pages. A shopper enters credit card details; a skimmer captures them. That framing is accurate but incomplete.
Lead generation landing pages – the ones advertisers send paid traffic to every day, collecting email addresses, phone numbers, and occasionally trial payment details – carry the same vulnerability and attract far less scrutiny.
If you run campaigns to a landing page with any form on it, the threat is real, and the signal that something is wrong will often not appear in your campaign data at all.
Contents
Key Takeaways
- Formjacking injects malicious JavaScript into a page to intercept form submissions before they reach the legitimate server.
- Lead gen landing pages are targeted for the same reason as checkout pages: dense, predictable data flowing through a predictable UI element.
- Two distinct attack vectors – supply-chain script compromise and browser-side injection – require different defenses and leave different fingerprints.
- The ‘double-submit’ technique makes the attack invisible to the advertiser’s conversion tracker: the legitimate form submission completes normally, the postback fires, and nothing in campaign reporting looks wrong.
- Server-side defenses don’t fully cover browser-side injection; the two threat models have different owners and different fixes.
Why Lead Form Data Gets Targeted
The standard narrative focuses on payment card data because that’s the quickest path to direct financial fraud. But email addresses, phone numbers, and full names submitted through a lead form have their own market. Stolen lead sets are sold as warm marketing lists, used for phishing campaigns, or matched against other compromised databases to build richer identity profiles.
For advertisers, there’s an added consequence beyond user harm: a competitor in the same vertical can buy the same scraped leads. The advertiser paid to acquire the contact; the attacker extracted it and sold it to whoever would pay. The advertiser’s campaign budget effectively subsidized a competitor’s list.
Paid traffic landing pages are a specific target for a structural reason. They’re built to move fast. Third-party tag stacks – analytics, heatmaps, chat widgets, A/B testing tools – are bolted on with minimal security review. Speed is the point of a lander, not a shortcoming of it, and a page that has to be live before the campaign starts rarely gets a Content Security Policy header or an integrity audit of every loaded script. Attackers are working against that constraint.
Two Attack Paths, Two Different Problems
These two mechanisms are commonly conflated, but the defenses for each sit in different places.
Supply-chain script injection is the variant most often documented in security research. The attacker doesn’t need to touch the landing page itself. Instead, they compromise a third-party JavaScript file that the page already loads: an analytics library, an A/B testing tag, a chat widget, a tracking pixel hosted on an external CDN. When the compromised script loads, it runs in the page’s context with access to the DOM, including any form inputs the user fills in. The Magecart campaigns analyzed by Unit 42 are the canonical example: actors injecting skimmers into pages not by breaking into the advertiser’s server, but by compromising a dependency the page trusted implicitly.
This is a supply-chain problem. The advertiser is a victim of their dependency graph, not of a direct breach. A February 2025 case documented by Sucuri shows how thin the line is. On a compromised Magento store, the skimmer was delivered through the site’s own Google Tag Manager container, with the encoded payload stored in the site’s database and served from googletagmanager.com like any other tag. The entry point there was the site itself rather than a third-party dependency, but the delivery surface is the same one this section is about: a trusted tag container nobody was auditing.
Browser-side injection shifts the problem to the user’s device, which is why it behaves so differently from the first vector. When a user visiting your landing page has malware or a compromised browser extension installed, the attacker’s code runs in the user’s browser regardless of how secure your page is. The page itself may be clean; the environment in which it loads is not. Extensions with broad DOM permissions can intercept keystrokes and form values before a submit event fires, meaning the data is captured at the input layer, not the network layer. This vector is outside the page owner’s direct control, which is precisely what makes it hard to address.
Formjacking Attack Vectors
| Comparison | Supply-Chain Injection | Browser-Side Injection |
|---|---|---|
| Attack entry point | A third-party script the landing page already loads, such as an analytics tag, chat widget, or CDN-hosted library. | The user’s own browser, through malware or a compromised extension with broad DOM permissions. |
| Who the attacker compromises | A dependency in the page’s script stack—not the page itself. | The user’s device environment before the page is loaded. |
| What the page owner controls | Tag inventory, SRI hashes, CSP headers, and dependency audits. | Very little—the compromise occurs outside the page’s own security perimeter. |
| Primary defense layer | Server and build layer: script integrity, strict CSP, and third-party tag audits. | Platform and endpoint layer: anti-fraud JavaScript monitoring, anomalous behavior detection, and endpoint hygiene. |
The Double-Submit Problem
Formjacking on lead gen pages stays undetected so often because of a technique called the double-submit: after capturing the form data, the skimmer either silently re-submits it to the legitimate endpoint or shows the user a fake error message (“Something went wrong, please try again”). The user submits again. The second submission reaches the real server. The advertiser’s postback fires. The CRM logs the lead. Nothing in the campaign report looks wrong.
This is what separates lead form skimming from most ad fraud. Bot traffic distorts conversion metrics: your conversion rate looks off, your CPA climbs, traffic-quality reports flag anomalies. Formjacking leaves the conversion metrics clean because an actual conversion happened. The only thing missing from the advertiser’s view is that the user’s data was sent somewhere else first.
The signal that something is wrong rarely shows up in campaign analytics. It surfaces downstream: users reporting that they submitted a form on your landing page and then received unsolicited calls from an unrelated party, or sales team complaints about contacts who have no memory of registering.
The Double-Submit Formjacking Chain
A real conversion happens, so the campaign report stays clean while the data is already gone.
-
01
User submits the form
A visitor fills in the lead form and clicks submit.
-
02
Script intercepts input
Injected code reads the field values on submit.
-
03
Data leaves silently
Values go to the attacker’s endpoint without anything visible.
-
04
Resubmit or fake error
The script re-sends the form or shows a fake error.
-
05
Real submission lands
The legitimate request reaches the advertiser’s server.
-
06
Tracker shows success
The postback fires and the CRM logs a normal lead.
conversion OK
Bot traffic distorts the numbers, so it appears in reporting. Here, a real person converts, so the metrics remain accurate—they simply do not show everything that happened.
What You Can Do About It
The defenses split along the same line as the two attack vectors.
For supply-chain injection, the most effective controls are at the build level. Subresource Integrity (SRI) lets you specify a cryptographic hash for externally loaded scripts; if the script changes, the browser refuses to execute it. This directly addresses the scenario where an attacker modifies a CDN-hosted library. The limitation: SRI requires you to update the hash whenever the legitimate script is updated, and it doesn’t cover scripts loaded dynamically at runtime – which many tag managers do by design.
Content Security Policy (CSP) headers can restrict which domains are allowed to load scripts and block outbound requests to domains you didn’t authorize, which would stop the data exfiltration step even if an injector ran. In practice, most landing pages have enough third-party dependencies that a strict CSP breaks something before it’s fully enforced. It’s worth doing, but it takes time to tune correctly.
One practical warning before you start: the first thing a strict CSP usually breaks is your own measurement. Tracking pixels, postback scripts, and tag containers all load from external domains, and a policy written without them will silently drop conversions rather than throw an error you notice. Build the allowlist from a real inventory of what the page loads, deploy in report-only mode first, and read the violation reports before enforcing. Where the option exists, moving conversion tracking to server-to-server postbacks removes it from the browser entirely, which takes it out of reach of both attack vectors described here.
The simplest habit that’s most consistently skipped is auditing your third-party tag stack – understanding what every loaded script is, where it’s hosted, and who controls it. The Magento skimmer described above is the argument for doing it. The malicious tag lived inside a container the site had authorized, loading from a Google domain, which means no domain-level check would have flagged it. A tag inventory would have – someone would have had to notice a container entry nobody could account for.
For browser-side injection, the page owner has limited leverage. The compromise exists on the user’s device. Server-side CSP doesn’t restrict what a browser extension does inside its own content script context. What you can do is reduce unnecessary surface area: load only the third-party scripts you genuinely need, use server-side form validation so submission patterns are harder to silently duplicate, and consider anti-fraud tooling that monitors for anomalous submission behavior – multiple submit events from the same session, interaction timings that don’t match human behavior, or data leaving the page to unexpected endpoints.
Honest Limits
A well-implemented Content Security Policy substantially closes the supply-chain vector, but it doesn’t reach the browser. Browser-side injection runs in a context the page’s own security headers can’t govern. SRI protects statically referenced scripts; it doesn’t protect against a tag manager injecting scripts dynamically after load. And because the double-submit technique keeps conversion data clean, you may not know exposure has been running until a user reports post-submission spam.
No single control covers the full attack surface. The realistic approach is layered: tighten the dependency chain, enforce CSP where feasible, monitor outbound script behavior, and treat user complaints about post-submission phishing as a security signal worth investigating rather than a routine support ticket.
Frequently Asked Questions
Is formjacking only a risk for e-commerce pages?
No. Any page collecting personally identifiable information through a form is a target. Lead gen landing pages collecting emails and phone numbers are attractive precisely because they’re less hardened than payment pages and process high data volumes.
Will campaign metrics show anything unusual if my landing page is being skimmed?
Usually not. The double-submit technique lets the legitimate conversion complete normally, so CRM and postback data look clean. The signal is more likely to surface in user complaints about phishing contact after submitting your form.
Does HTTPS prevent formjacking?
No. HTTPS protects data in transit between the user’s browser and your server. Formjacking captures the data inside the browser before it’s transmitted anywhere.
Can a Content Security Policy stop formjacking completely?
A strict CSP can block unauthorized scripts from loading and prevent data from being sent to unauthorized domains – which addresses supply-chain injection effectively. It doesn’t stop injection originating from a browser extension, which runs outside the page’s own security context.
How do I know if a third-party script on my landing page has been compromised?
Regular tag audits, SRI hashes on external scripts, and monitoring outbound network requests from your page are the most reliable methods. Some security tools alert on unexpected changes to loaded script content or anomalous form behavior.
Start with the Supply-Chain Vector
The attack path most landing pages are most exposed to is supply-chain compromise: a tag manager, analytics pixel, or chat widget whose external script gets modified without anyone noticing. That’s where to focus first, and it’s the vector where standard developer controls – SRI, CSP, periodic dependency audits – actually work.
Browser-side injection is harder to address at the page level, but it’s also lower-frequency for any given lander, since it requires a compromised user environment rather than a compromised dependency. Keeping the two threat models separate – and knowing which team owns each fix – is more useful than treating formjacking as one problem with one solution.