TL;DR: how form-based skimmers steal card data
- Your WAF and your CSP will both tell you the checkout is clean while card data is leaving the browser. Both controls sit at the network layer, and the theft happens inside the DOM, on a script served from a domain your allowlist already trusts.
- Visa attributes 70% of payment card theft to the client layer, and British Airways lost around 380,000 records over 22 days before paying a 20 million pound ICO fine. cside hashes every script payload in real browser sessions and alerts the moment a hash changes.
- If you cannot answer whether a trusted-domain script was modified in the last hour, you are one payload swap away from being the next case study.
Formjacking is a web attack that injects malicious JavaScript into a payment or checkout page to steal card data as a visitor types it. The script reads form field values in real time, sends them to an attacker-controlled server, and lets the original transaction complete normally. The shopper gets a confirmation, the merchant sees a completed sale, and the card details are already gone. Because the theft happens inside the browser, it stays invisible to the network- and server-layer controls most merchants rely on.
How formjacking works: step by step
Formjacking is an execution-layer attack. It does not require a network breach or a server compromise. Here is how it plays out.
-
An attacker injects malicious JavaScript into a payment or checkout page. This is usually done by compromising a third-party script the merchant already loads, such as a tag manager, analytics library, or CDN-hosted utility.
-
When a visitor reaches the payment form, the injected script starts intercepting keystrokes or field values in the browser's Document Object Model. It does not need to wait for form submission.
-
As the visitor types their card number, expiry date, and CVV, the script captures those values and exfiltrates them to an attacker-controlled server in real time. The transfer is usually encoded to avoid obvious network-layer detection.
-
The original form keeps working. The payment is processed, the visitor receives a confirmation, and nothing in their browser or the merchant's server logs flags anything unusual.
This is why formjacking is so dangerous. There is no error, no failed transaction, and no anomaly at the network or server layer. The attack is invisible to the controls most merchants have in place.
British Airways 2018: what happened
In 2018, a Magecart threat actor injected a formjacking script into the British Airways booking site and operated undetected for 22 days, compromising around 380,000 customer payment records including card numbers, expiry dates, CVVs, and personal information. Internal systems did not catch it during that window because no payload-level monitoring was in place.
The attack modified a script that was already present on the site, so no new script URLs appeared. No Content Security Policy rule fired, because the domain serving the modified script was already on the allowlist.
The ICO investigation resulted in a £20 million fine. The root-cause finding identified the failure to detect a payload change inside a trusted script as the central technical failure.
Visa reports that a large majority of payment card theft now happens at the client layer, in the browser, rather than on the server or in transit:
| Where card data is stolen | Share of theft |
|---|---|
| Client layer (browser / DOM) | 70% |
| Server / network layer | 30% |
Source: Visa. Formjacking is the primary mechanism behind that 70%.
Formjacking and Magecart: what each term means
Magecart is a threat-actor category, not a technique. The name refers to a loose collective of criminal groups that use formjacking as their primary method of attack.
Formjacking is the technique: injecting JavaScript to intercept and exfiltrate form data. Magecart groups are among the most prolific users of that technique, but they are not the only ones.
When researchers and journalists use the terms interchangeably, they are usually describing a Magecart-attributed formjacking attack. The distinction matters for detection. You are not looking for a specific group's signature; you are looking for the behavior of payload interception, whoever is behind it.
Why WAFs and CSPs do not stop formjacking
A web application firewall inspects HTTP traffic at the network layer. It sees requests and responses between the browser and the server, but it has no visibility into what JavaScript executes inside the DOM after the page loads. A formjacking script lives entirely in the DOM. It does not generate a suspicious request to the merchant's server; it posts the stolen data straight to an attacker-controlled endpoint.
A Content Security Policy restricts which domains are allowed to serve scripts, and it is a useful control. But a formjacking attack usually modifies a script served from a domain the CSP already trusts. The domain passes the allowlist check, and the payload itself is never inspected. This is the same gap Visa points to when it attributes roughly 70% of card theft to the client layer, where WAFs and server-side controls have no line of sight.
How cside script monitoring detects formjacking
Real-session script monitoring detects formjacking by hashing every script payload as it executes inside a genuine browser environment, then alerting the moment any hash changes. This catches payload injection inside trusted scripts that a CSP allowlist and a WAF both miss.
cside script monitoring runs in real browser sessions and combines 100+ signals per session into a real-time verdict.
When a formjacking payload is injected into a trusted script, the hash of that script changes. cside detects the change in near real time and fires an alert that includes the script identifier, the previous hash, the new hash, and a timestamp. The alert lands before the compromised script can accumulate a meaningful volume of stolen data.
cside's fingerprinting holds high accuracy across incognito, VPN, and cookie-clearing sessions, and its monitoring methodology is validated by VikingCloud.
The PCI DSS requirement that specifically targets formjacking
PCI DSS Requirements 6.4.3 and 11.6.1 were introduced specifically to address the formjacking risk, and they became mandatory on 31 March 2025.
Requirement 6.4.3 asks merchants to inventory every script on payment pages, document a business justification for each, obtain explicit authorisation, and verify integrity on an ongoing basis. This directly targets the scenario where a trusted script is modified without the merchant's knowledge.
Requirement 11.6.1 requires an alert mechanism that fires when payment-page headers or content change in an unauthorized way. The near-real-time detection that cside provides meets and exceeds what QSAs look for when they review 11.6.1 evidence.
Check your payment pages for injection risk and start free with cside PCI Shield. For how the terms relate, see formjacking vs Magecart vs digital skimming, and for how continuous monitoring works in practice, see the top platforms for third-party script monitoring.
