What is Formjacking: How Hidden Scripts Steal Payment Data
Formjacking hides malicious code inside legitimate shopping pages, allowing attackers to capture payment details before encryption occurs.
Formjacking is a cyber attack where malicious scripts are injected into legitimate web forms to steal sensitive data like credit card numbers. Attackers intercept input before it reaches the payment processor. Defenses include Content Security Policy headers, Subresource Integrity checks, and rigorous third-party script auditing to prevent unauthorized code execution.
Start with the Digital Wallet Analogy
Imagine handing your credit card to a cashier. You trust the store, so you do not worry. Now imagine a second person standing behind the counter who copies your card details before the cashier processes the transaction. You never saw this second person. You trusted the environment. Formjacking operates on this exact principle of broken trust within a familiar interface.
What Is Formjacking and Why It Matters
Formjacking is a technique where attackers inject malicious JavaScript into a website’s payment forms to steal sensitive information. The user visits a legitimate e-commerce site and enters their credit card number. The malicious script captures this input in real time. It sends the data to an attacker-controlled server before the legitimate payment processor receives it. The transaction often completes normally, so the user sees no error message.
This method exploits the complexity of modern web applications. Sites rely on dozens of external scripts for analytics, chat support, and advertising. Each external connection is a potential entry point. If an attacker compromises one of these third-party providers, they can push malicious code to every site that uses it. The damage scales rapidly because the trust is already established.
| Aspect | Detail |
|---|---|
| Primary Vector | Compromised third-party scripts or direct site injection |
| Target Data | Credit card numbers, CVV codes, billing addresses |
| Detection Difficulty | High, as code runs within trusted domains |
| Common Prevention | Content Security Policy and Subresource Integrity |
| User Impact | Financial theft and identity exposure |
| Attack Scope | Single site or entire supply chain |
How the Injection Mechanism Works
Attackers need a way to place their code on the victim’s browser. They rarely hack the main server directly if they can avoid it. Instead, they target the supply chain. A popular widget provider for live chat or customer reviews might have a vulnerability. The attacker exploits this weakness to update the script’s behavior. When the script loads on your browser, it now contains the formjacking payload.
The payload listens for input events on specific HTML elements. It looks for fields labeled "card number" or "expiry date." When you type, the script intercepts the keystrokes or reads the value from the DOM. It formats this data and sends it via an HTTP request to a remote server. This happens in milliseconds. The legitimate form still submits to the payment gateway. The user perceives no delay or disruption.
This approach differs from phishing because the user is on a genuine website. It also differs from man-in-the-middle attacks because the connection between the browser and the server remains encrypted via HTTPS. The theft occurs at the application layer, inside the browser, before encryption wraps the data for transmission. Understanding this distinction is vital for choosing the right defense.
Who Gets Hit and Why
E-commerce platforms are the primary targets. Any site that processes payments online is vulnerable. However, the risk extends to any organization using web forms for sensitive data. Insurance claims, banking applications, and healthcare portals all use forms that can be hijacked. Small businesses are often easier targets because they lack the resources to audit every third-party script they embed.
Attackers choose targets based on transaction volume and security maturity. A site with high traffic offers more data per minute. A site with outdated security headers offers an easier path for injection. The attacker does not need to trick the user. They only need to compromise the code that the user’s browser trusts. This shifts the burden of security from the user’s vigilance to the developer’s configuration.
EXAMPLE: The Hidden Chat Widget
See also: Password Spraying vs Stuffing: Mechanics, Detection, and Defense
What People Usually Get Wrong
Many teams believe that HTTPS prevents formjacking. This is incorrect. HTTPS protects data in transit between the browser and the server. It does not protect data sitting in the browser’s memory before it is sent. The malicious script runs in the same context as the legitimate page. It has full access to the DOM. Encryption starts after the script has already stolen the values.
Another common error is focusing only on the main domain. Security teams often monitor their own servers for anomalies. They forget that the malicious code comes from a third-party domain. The traffic leaving the user’s browser looks like normal analytics data. Blocking external scripts entirely breaks functionality. Allowing them all invites risk. The balance lies in strict validation of what is allowed to run.
Teams also underestimate the role of social engineering red flags in the initial compromise. The third-party provider might have been tricked into installing the malicious code. An employee might have clicked a link in a spear phishing email. The formjacking is the technical execution, but the entry point is often human error elsewhere in the supply chain.
Defending Against Script Injection
Content Security Policy (CSP) is the primary defense. CSP is an HTTP header that tells the browser which sources are allowed to load scripts. You can configure it to allow scripts only from your own domain and specific trusted partners. This blocks inline scripts and unknown external sources. It reduces the attack surface significantly. If a malicious script tries to load from an unauthorized domain, the browser refuses to execute it.
Subresource Integrity (SRI) adds a second layer. SRI requires a cryptographic hash for each external script. The browser calculates the hash of the downloaded script and compares it to the expected value. If they do not match, the browser blocks the script. This prevents attackers from modifying a legitimate script on a third-party server. Even if they compromise the provider, the browser will refuse to run the altered code.
Monitor outbound network traffic for anomalies. Look for requests to unknown domains or unusual data sizes. Implement anomaly detection on your payment gateways. If a card number appears in logs before the transaction is authorized, it may indicate interception. Regularly audit all third-party integrations. Remove any widgets or scripts that are no longer necessary. Each external dependency is a potential vector.
Checklist for Hardening Web Forms
- Implement strict Content Security Policy headers to restrict script sources.
- Enable Subresource Integrity for all external JavaScript libraries and widgets.
- Audit third-party vendors for security practices and incident history.
- Monitor network traffic for unexpected outbound data transfers.
- Minimize the number of third-party scripts loaded on payment pages.
- Test forms with security tools to detect hidden data exfiltration attempts.
The Broader Attack Context
Formjacking is part of a larger attack lifecycle focused on financial gain. It sits between initial access and impact. It requires no direct interaction with the victim after the page loads. This makes it efficient for large-scale operations. It complements other tactics like password spraying or phishing simulations by targeting high-value data at the point of entry.
Understanding formjacking helps you see the limits of traditional perimeter security. You cannot just lock the doors. You must verify everything that enters the house. You must assume that third-party connections are untrusted until proven otherwise. This mindset shift is necessary for modern web security. The threat is not just outside the firewall. It is often inside the browser, waiting for input.
Key takeaways
- Malicious code often hides within trusted third-party analytics or chat widgets, bypassing standard perimeter defenses.
- Subresource Integrity hashes verify that loaded scripts have not been altered since the publisher signed them.
- Monitoring for unusual outbound network traffic helps detect data exfiltration even when the payload looks legitimate.
Formjacking steals data before encryption by hijacking trusted web scripts. Implement Content Security Policy and Subresource Integrity to validate every line of code that runs in your browser.
Frequently asked questions
Can antivirus software detect formjacking?
Traditional antivirus focuses on files on your device. Formjacking happens in the browser memory and involves network requests. Endpoint detection tools may catch suspicious behavior, but browser-level controls like CSP are more effective.
Does using a virtual card stop formjacking?
It limits financial damage if data is stolen. The attacker still captures the card number. However, if the number is single-use or has low limits, the value to the attacker decreases. It does not prevent the theft itself.
How do I know if my site is compromised?
Look for unexpected scripts in your page source. Check for outbound requests to unknown domains. Use browser developer tools to monitor network activity. Sudden changes in third-party script hashes are a strong indicator.
Is HTTPS enough to prevent this attack?
No. HTTPS encrypts data in transit. Formjacking captures data in the browser before encryption. You need application-layer defenses like CSP and SRI to prevent the malicious script from running or modifying other scripts.
How this guide was produced: written by the TechSec Feed 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.
