Formjacking is a type of cyber attack where malware hijacks online forms to steal sensitive information like credit card numbers. It typically occurs when attackers compromise a website’s scripts or inject code directly into the browser. The stolen data is sent to the attacker before the legitimate transaction completes, bypassing standard security checks.
The Invisible Thief at the Checkout
Imagine handing your credit card to a shop assistant who slips a magnetic stripe reader under the counter. You see the legitimate terminal, the staff member, and the receipt. You assume the transaction is secure. Formjacking operates on this same principle of deception. It does not break into your bank account directly. Instead, it intercepts the data you willingly type into a web form.
The victim believes they are interacting with a trusted merchant. The browser renders a legitimate-looking checkout page. Behind the scenes, however, a malicious script is listening. It captures keystrokes or reads form fields the moment you submit them. This happens before the data is encrypted and sent to the payment processor.
At a Glance
| Aspect | Detail |
|---|---|
| Primary Target | E-commerce checkout pages and login forms |
| Attack Vector | Injected JavaScript or compromised third-party scripts |
| Data Stolen | Credit card numbers, CVVs, names, and addresses |
| Detection Difficulty | High, as traffic often appears legitimate to gateways |
| Common Entry Point | Vulnerable plugins, analytics tools, or CMS updates |
How the Injection Occurs
The attacker needs a way to place their code on the page you visit. This usually happens through two main paths. The first is server-side compromise. The attacker gains access to the website’s backend, perhaps through weak credentials or an unpatched vulnerability. They then modify the HTML or JavaScript files that render the checkout page.
The second path is more subtle and harder to detect. It involves third-party scripts. Modern websites rely on external services for analytics, chat widgets, or payment buttons. If any of these external providers are compromised, or if the attacker can exploit a cross-site scripting vulnerability in your site, they can inject their payload. Your browser loads the malicious script alongside the legitimate code. To you, the page looks normal. To the attacker, your input is now visible.
Why Payment Gateways Miss It
This is where formjacking diverges from typical fraud. If an attacker steals a credit card number from a dark web forum and uses it to buy items, the payment gateway sees a transaction from a known user with valid details. If the attacker uses formjacking, they are not entering the data themselves. You are.
When you submit the form, the data is sent to the payment processor via the standard secure channel. The processor sees a valid request from a legitimate user agent. It sees the correct address and card details. Because the transaction originates from the real customer’s browser, many automated fraud filters approve it. The attacker has already received a copy of the data via a separate, hidden channel. The payment gateway is essentially tricked into processing a legitimate transaction that has already been skimmed.
This means that login alerts or transaction notifications you receive from your bank will look normal. The amount matches, the merchant name is correct, and the location is plausible. The alert system cannot distinguish between you paying for a purchase and the attacker having also seen the data.
Common Forms of the Attack
Attackers adapt their methods based on the target’s technology. Client-side formjacking occurs in the browser. The malicious JavaScript runs on your machine. This is often delivered through phishing kits that mimic popular e-commerce platforms. If you click a link that looks like a real store but hosts a fake version, the script runs immediately upon loading the page.
Server-side formjacking is more persistent. The attacker modifies the actual files on the web server. This affects every visitor who loads the page. This method is often used against smaller merchants who use content management systems with outdated plugins. The attacker exploits a known flaw in a plugin to upload a malicious file. This file then intercepts all form submissions on that site.
A third variant involves DNS filtering evasion. Attackers may use domain generation algorithms to create new command-and-control servers frequently. This makes it difficult for security teams to block the destination where the stolen data is sent. By the time a domain is blacklisted, the attacker has already moved to a new one.
See also: DNS Filtering: What It Blocks and What It Misses
What People Usually Get Wrong
Many security teams assume that using HTTPS prevents formjacking. This is incorrect. HTTPS encrypts the data between your browser and the server. It protects the data in transit from network sniffers. It does not protect you if the server itself, or the script running in your browser, is malicious. The encryption works exactly as designed, carrying the stolen data to the attacker’s server just as securely as it carries it to the payment processor.
Another common misconception is that two-factor authentication stops this attack. Vendor email compromise often uses similar social engineering tactics, but formjacking is technical, not social. You are not being tricked into clicking a link to a fake login page in the traditional sense. You are often on the real site. Two-factor authentication secures your account access, but it does not prevent a script from reading the form fields on a public checkout page.
Finally, some believe that using a virtual card or privacy service eliminates the risk. While these tools limit the damage by providing disposable numbers, the attacker still obtains the data. They can test the virtual card immediately. The privacy service may flag the rapid transaction, but the initial theft has occurred. The data is still in the wild.
Reducing the Risk
Defending against formjacking requires a shift in perspective. You cannot rely solely on perimeter defenses. You must assume that some code on your page might be untrusted.
- Subresource Integrity: This is a browser feature that allows you to verify that a script fetched from a third party has not been tampered with. You include a cryptographic hash in the script tag. If the downloaded script differs from the expected hash, the browser refuses to run it. This prevents attackers from modifying third-party scripts to inject malware.
- Content Security Policy: This HTTP header tells the browser which sources of scripts are allowed to run. By restricting script execution to known, trusted domains, you reduce the attack surface. You must configure this carefully, as overly strict policies can break legitimate functionality.
- Monitor for Anomalies: Look for unusual spikes in form submissions or data exfiltration patterns. While the payment gateway may not flag the transaction, your own web application firewall or intrusion detection system might see strange outbound requests from your server to unknown IPs.
The Hidden Cost of Trust
The most significant challenge with formjacking is the erosion of trust. When an attack occurs, customers blame the merchant. They do not understand that the merchant’s site was compromised. They assume their data was stored insecurely. This reputational damage can be long-lasting.
Furthermore, the investigation is complex. You must determine whether the compromise was in your own code, a third-party plugin, or a browser-side injection. This requires deep packet inspection and log analysis. You may need to review every script loaded on the checkout page. This is time-consuming and requires specialised skills.
Consider how this relates to rainbow table attacks. Both involve stealing data to bypass security. In a rainbow table attack, stolen hashes are cracked to reveal passwords. In formjacking, live data is captured before it is even hashed or encrypted by the payment processor. Both highlight that securing the perimeter is not enough. You must secure the data at every stage of its journey.
Key takeaways
- The attack happens in the user's browser or on the server, meaning the payment gateway often sees no anomaly.
- Compromised third-party plugins and analytics scripts are common entry points, not just the main website code.
- Standard web application firewalls may miss these attacks because the injected code often mimics legitimate traffic patterns.
Formjacking bypasses traditional payment security by stealing data before it is encrypted for the merchant. Implement Subresource Integrity and strict Content Security Policies to verify that every script on your page is legitimate.
Frequently asked questions
Can formjacking happen on mobile apps?
Yes, if the app loads web views or uses embedded web forms, the same injection techniques can apply. Native apps are harder to inject but can still be compromised through outdated libraries.
Does using a payment token prevent formjacking?
Tokenisation helps, but if the attacker captures the data before it is tokenised, they still have the raw card details. The goal is to prevent the capture at the source.
How long does it take to detect a formjacking attack?
Detection time varies. Without specific monitoring for script anomalies, it can take weeks or months. Automated tools that check script integrity can detect it immediately.
Is formjacking the same as skimming?
Skimming usually refers to physical devices on card readers or ATMs. Formjacking is the digital equivalent, targeting online forms rather than physical cards.
How this guide was produced: written by the Payload Report editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
