What is formjacking?
The mechanism behind most card skimming: two implementations, each with a different structural fingerprint and a different detection route.
TL;DR
Formjacking
WHAT IT IS
Malicious code that hijacks a web form to capture what a visitor types, most commonly payment card details at checkout.
TWO IMPLEMENTATIONS
Listen to the existing form, or replace it with an identical one you control and pass the data through.
RELATION TO OTHER TERMS
Formjacking is the mechanism. Web skimming is the outcome. Magecart names the groups. They describe the same incidents.
Short on time? The replaced-form variant is harder to see and easier to detect structurally.
What is formjacking?
Formjacking is an attack in which malicious JavaScript takes control of a web form so that the information a visitor types into it is copied to an attacker before, or as well as, reaching its intended destination. The term describes the mechanism rather than the target, so formjacking can apply to any form worth stealing from: a checkout, a login, an insurance quote or a patient intake form. In practice it is most associated with payment pages, where it is the mechanism behind what is otherwise called web skimming, e-skimming or a Magecart attack.
Blocking by hash pins the exact payload you approved, so a vendor that ships new code has to be re-approved rather than silently inherited.
The two implementations
1
Listen to the existing form
The script attaches event listeners to the real inputs and reads values on keystroke, change or submit. The form on the page is genuinely yours, so it looks correct in the DOM. Detection comes from noticing which script is reading those fields.
2
Replace the form
The script removes your form and inserts a visually identical one it controls, collects the data, then forwards it so the purchase completes. Visually indistinguishable, and structurally obvious: the form is no longer the one your application rendered.
Why it works so well
JavaScript on a page has full access to the DOM of that page. There is no privilege boundary between the script you wrote and the script your analytics vendor's vendor loaded. Both can read any input on the page. The browser has no concept of 'this script is allowed to touch the card field and that one is not', which is precisely the gap PCI DSS 6.4.3 is trying to close administratively.
Most tags on a checkout have no reason to touch the card field.
Detecting each variant
Signal
Catches listener variant
Catches replaced-form variant
Script reading payment inputs
Yes, directly
Yes
Form structure differs from what was rendered
No
Yes, clearly
New outbound destination
Yes
Yes
Unapproved script in the inventory
Yes, if the script is new
Yes, if the script is new
Changed payload hash on an approved script
Yes, compromised-vendor case
Yes
Removing the capability rather than the script
The useful middle option on a payment page: keep a vendor script running while removing its ability to read form fields. Most tags on a checkout have no legitimate reason to touch the card input, and removing one capability is a smaller and more defensible action than removing a vendor the business wants.
Sources and methodology
PCI DSS requirement text is quoted from PCI DSS v4.0.1 (June 2024), published by the PCI Security Standards Council, which is the current version at the time of writing. Requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. Where we describe a competitor, we describe publicly available information and say so when something should be verified with the vendor. We publish this product and that is a bias worth knowing about while you read.
ASK AN AI
Don’t just take our word for it
Ask your assistant what to look for in a tool for PCI DSS 6.4.3 and 11.6.1.
Frequently asked questions
Yes in practice. Formjacking is the mechanism and Magecart names the groups who use it. An incident described as Magecart is almost always formjacking underneath.
No. Any form worth stealing from can be targeted: logins, insurance quotes, patient intake, account registration. Payment forms attract the most attention because card data has immediate resale value.
Partly. A CSP can prevent an unlisted origin loading a script and can restrict where data is sent, which helps. It cannot tell you that an allowed script is reading your card field.
By passing the data through: the attacker's form collects the details, then submits them to the real endpoint so the purchase completes and the customer receives their order. Nothing appears wrong from the customer's side.
Partly, and it raises the cost. Client-side encryption of field values means a listener captures ciphertext rather than a card number. A script that replaces the form controls the encryption step too, so it is not a complete answer.
No, and that is what makes it difficult. The usual route is a compromised third-party script or tag manager, so your own infrastructure is untouched and your logs show nothing.
Yes. Browser autofill populates fields programmatically, and a listening script sees those values the same way it sees typed ones.
Quickly, which is part of the problem. Skimmer kits are sold ready to configure, so the time between compromising a script and collecting card data can be minutes.
Blocking, at whichever granularity fits: the whole script by URL or hash, the whole origin by domain, or just the capability to read form fields if you need the script to keep working.
Yes, it is the attack requirements 6.4.3 and 11.6.1 were written to address. 6.4.3 asks you to know and authorise every script on the page; 11.6.1 asks you to detect when the page changes.
Related articles
Attacks
What is Magecart? Groups, methods and real incidents
Where the name came from, how the attacks work, and why they run for months undetected.
Attacks
What is web skimming? How card data leaves the browser
The technique, the exfiltration methods, and why your server logs show a successful checkout.
Attacks
Shadow code: the scripts nobody approved
Code executing on your pages that no one on your team chose, and how it gets there.
Attacks
Homoglyph attacks: when a domain is not the domain
Characters that render identically, and why they work so well against script allowlists.
See every script on your own checkout.
Install the tag, mark your payment pages, and watch the inventory fill in. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.