Skip to main content
Commerce Security Authority
Category: Fraud Typologies

Formjacking

Also known as: form hijacking
Simply put

Formjacking is a cyberattack in which criminals inject malicious code into a website's forms, most often the payment or checkout page, to secretly capture the information a customer types in. Because the stolen data, such as card details entered on a payment page, is intercepted as the shopper submits the form, the attack can occur without the customer or the merchant noticing. It has been described as a form of man-in-the-middle attack, since it intercepts communications between the user and the website.

Formal definition

Formjacking refers to the unauthorized injection of malicious JavaScript into a website's form fields—commonly on checkout or login pages—to skim data entered by users, including payment card details and other sensitive authentication or credential information. The injected script executes in the client browser and intercepts form input at or before submission, functioning as a client-side man-in-the-middle interception between the user and the intended endpoint. Because the data captured can include cardholder data such as the PAN and, on payment forms, sensitive authentication data such as CAV2/CVC2/CVV2/CID entered during checkout, formjacking is a concern for the security of client-side payment page scripts; the specific controls that govern script integrity and monitoring on payment pages should be confirmed against the current published PCI DSS.

Why it matters

Formjacking targets the client side of a web application—the browser environment where a customer actually types their information—rather than the merchant's back-end servers. This makes it particularly difficult to detect, because the malicious JavaScript executes in the shopper's browser and can capture data at or before submission without triggering server-side alarms. As a result, an attack can persist for an extended period while neither the customer nor the merchant notices that form input is being intercepted.

The data at risk on a payment or checkout page can include cardholder data such as the PAN, as well as sensitive authentication data such as CAV2/CVC2/CVV2/CID that a customer enters during checkout. Sensitive authentication data must not be stored after authorization, yet formjacking captures it precisely at the moment of entry, before the merchant's own storage and control decisions come into play. This makes the integrity and monitoring of client-side scripts on payment pages a meaningful security concern. The specific controls governing payment page script integrity and change detection should be confirmed against the current published PCI DSS, as requirement wording and numbering differ between versions.

Because formjacking operates through third-party or injected scripts loaded into the payment page, it also highlights the risk introduced by the many external scripts commonly present on modern checkout pages. A compromise of any script with access to form fields can expose the data a customer submits, which is why script inventory, integrity verification, and monitoring are central to reducing this exposure rather than any single detection control.

Who it's relevant to

E-commerce merchants
Merchants operating online checkout pages are the primary target of formjacking, since their payment forms are where cardholder data and sensitive authentication data are entered. They are responsible for the integrity of scripts loaded on those pages and for detecting unauthorized changes, and should confirm applicable client-side script requirements against the current published PCI DSS.
Security engineers and application security teams
Teams responsible for web application security need to inventory and monitor the scripts running on payment and login pages, verify their integrity, and watch for unauthorized JavaScript injection. Because formjacking executes in the client browser, server-side controls alone may not detect it, and monitoring approaches involve trade-offs in coverage and false positives.
Compliance officers
Those managing PCI DSS compliance should understand how client-side script integrity and monitoring obligations apply to payment pages. They should confirm the specific controls, wording, and requirement numbering against the current published standard rather than assuming a fixed reference, as these differ between versions.
Payment processors and service providers
Processors and third parties whose scripts or hosted components appear on merchant payment pages can become an avenue for formjacking if compromised. They share responsibility for the security of the code they deliver into the client browser and for supporting merchants' ability to detect and respond to unauthorized script changes.

Inside Formjacking

Malicious client-side script injection
The core mechanism of formjacking, in which an attacker injects unauthorized JavaScript into a payment or checkout page so that data entered by the cardholder is captured in the browser as it is typed, before or in parallel with legitimate form submission.
Targeted data fields
Formjacking scripts typically harvest cardholder data such as PAN, cardholder name, and expiration date, and may attempt to capture sensitive authentication data such as CAV2/CVC2/CVV2/CID entered during checkout. Because this data is intercepted at entry, controls that transform stored data (tokenization, truncation, masking) do not by themselves stop capture at the point of entry.
Third-party and supply-chain vectors
Injection often occurs through compromised third-party scripts, tag managers, content delivery networks, or other externally sourced code loaded into the payment page, meaning the merchant's own server may not be directly breached.
Exfiltration channel
Captured data is transmitted to an attacker-controlled endpoint, frequently disguised to resemble legitimate analytics or resource traffic to evade detection.
Relationship to PCI DSS scope
Payment pages and the scripts they load fall within the cardholder data environment. Requirements addressing the security and integrity of scripts on payment pages are relevant here; readers should confirm the specific applicable requirements against the current published PCI DSS version rather than assuming a fixed requirement number.

Common questions

Answers to the questions practitioners most commonly ask about Formjacking.

Is formjacking the same as skimming a physical card reader?
No. Formjacking refers to the injection of malicious code into a web page, typically a payment or checkout form, to capture data as the user enters it in the browser. Physical skimming involves a device attached to a card-present terminal or ATM. While both aim to harvest cardholder data, formjacking targets card-not-present environments and operates within the client-side context of a website, so the detection and control approaches differ substantially.
If my payment page uses TLS encryption, am I protected from formjacking?
No. TLS protects data in transit between the browser and the server, but formjacking code executes within the browser before or as data is submitted, so it can capture data prior to transmission. Encryption in transit does not address malicious script running in the page context. Controls such as script integrity monitoring and management of authorized scripts on payment pages address a different layer than transport encryption. Confirm the specific browser-script control requirements against the current published PCI DSS standard, as wording and numbering differ between versions.
What types of data can formjacking capture, and does storing them create additional obligations?
Formjacking can capture whatever the compromised form collects, which may include cardholder data such as the PAN, cardholder name, and expiration date, as well as sensitive authentication data such as CAV2/CVC2/CVV2/CID entered at checkout. Sensitive authentication data must not be stored after authorization even when encrypted, and formjacking is an unauthorized capture rather than a controlled storage scenario. The exposure of this data is a security incident regardless of your own storage controls, so treat it accordingly.
How can we monitor the scripts running on our payment pages?
Approaches include maintaining an inventory of authorized scripts, applying integrity mechanisms so that unauthorized or modified scripts can be detected, and monitoring for changes to scripts loaded in the payment page. These controls are intended to help detect unexpected code but may produce false positives when legitimate third-party scripts change, and they do not by themselves guarantee that all malicious injection is caught. Confirm the applicable script management and integrity requirements against the current published PCI DSS standard rather than assuming a fixed requirement number.
How does reliance on third-party scripts affect formjacking risk?
Payment pages that load scripts from third parties, such as analytics, tag managers, or content delivery services, expand the set of code that executes in the browser, and a compromise of any of those sources can introduce formjacking code. Managing this involves inventorying third-party scripts, justifying their presence on payment pages, and monitoring them for unauthorized change. The trade-off is operational, since more third-party integrations generally increase the monitoring burden and the potential attack surface.
Does using a hosted payment page or iframe reduce formjacking exposure and PCI DSS scope?
Redirecting or embedding the payment entry via a service provider's hosted page or iframe can move the data-entry surface off the merchant's own page, which may reduce the merchant's exposure and affect scope. However, the effect on PCI DSS scope depends on the specific implementation and how it is validated, not on the label alone, and the merchant page that frames or redirects can still be a target if it is compromised. Confirm the applicable validation and scoping expectations against the current published standard and your acquirer's guidance.

Common misconceptions

Formjacking requires the attacker to breach the merchant's back-end servers or database.
Formjacking operates on the client side in the customer's browser and commonly enters through compromised third-party or supply-chain scripts. The merchant's server-side systems and stored-data protections may be unaffected while data is still captured at the point of entry.
Encrypting or tokenizing stored cardholder data protects against formjacking.
Tokenization, encryption, truncation, and masking transform or reduce data at rest or in transit within controlled systems; they do not, by themselves, prevent a malicious in-browser script from capturing data as the cardholder types it before those controls apply.
TLS/HTTPS on the checkout page prevents formjacking.
TLS protects data in transit against interception between endpoints, but a malicious script running inside the page has legitimate access to form input and can exfiltrate it over its own connection. Transport encryption is intended to address a different risk and does not stop client-side script-based capture.

Best practices

Inventory and monitor every script loaded on payment pages, including third-party, tag manager, and CDN-sourced code, and authorize scripts explicitly so that unexpected or altered scripts are detected.
Implement integrity and change-detection controls for scripts on payment pages, such as monitoring for unauthorized modifications, to help identify injected or tampered code; recognize this reduces but does not eliminate risk.
Apply browser-side hardening such as Content Security Policy and Subresource Integrity where feasible to constrain which scripts may execute and where data may be sent, while noting these controls have configuration and coverage limitations.
Minimize exposure of the cardholder data entry point, for example by using validated approaches that keep account data entry off the merchant-controlled page, and confirm the scope and validation effect of any such approach against the applicable PCI DSS and related standards rather than relying on the label alone.
Vet and manage third-party and supply-chain code through vendor due diligence, version pinning, and prompt review of updates, since formjacking frequently enters through externally sourced scripts.
Confirm the specific applicable PCI DSS requirements governing payment page script security and integrity against the current published version, and align monitoring and detection controls accordingly.