TL;DR
- Online card skimming is malicious JavaScript on a merchant's checkout page that copies payment card details as the customer types them.
- Attackers place the script by compromising a third-party plugin, analytics library, or tag manager the site already loads.
- The stolen data leaves the browser directly to an attacker-controlled server. Your backend, WAF, and payment processor never see it.
- Visa's Spring 2025 Biannual Threats Report identifies digital skimming as "one of the most prolific and consistent threats" in the payments ecosystem.
- PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1, mandatory since March 31, 2025, exist specifically to counter this attack type.
What Is Online Card Skimming?
- Online card skimming
- Online card skimming is a cyberattack where malicious JavaScript runs in a shopper's browser on a merchant's checkout page. As the user types their card number, expiry date, CVV, and billing address into the payment form, the script copies that data and transmits it to a server the attacker controls, before the payment is submitted.
The term "card skimming" originates from physical fraud: a hardware device attached to an ATM or point-of-sale terminal that reads the card's magnetic stripe and records the PIN as a customer enters it. Online card skimming works on the same principle but needs no physical device. A few lines of JavaScript replace the hardware. The attack leaves no physical trace, can run undetected for months, and can be deployed across thousands of websites simultaneously through a single compromised third-party script.
Visa's Spring 2025 Biannual Threats Report identified digital skimming as one of "the most prolific and consistent threats" in the payments ecosystem, noting that the company's eCommerce Threat Disruption program actively scans merchant sites for skimmer signatures across North America and Europe.
For a complementary look at the browser-execution side of this attack, see our detailed e-skimming guide.
How Attackers Deploy Card Skimming Scripts
Attackers need code execution on the target checkout page. They get it through supply-chain entry points rather than attacking the merchant's server directly:
- A compromised third-party plugin, CMS extension, or widget the merchant's site already loads
- A malicious update pushed to a CDN-hosted analytics or tag manager library
- A breach of the merchant's CMS admin panel or code repository
Once they control a JavaScript file that runs on the payment page, they add the skimming payload. The script hooks into payment form fields. As the customer types, the script copies each value, encodes the data, and sends it over HTTPS to an attacker-controlled domain, typically a typosquatted lookalike designed to blend into network traffic logs. The exfiltration request never passes through the merchant's server.
Three properties make this nearly invisible from outside the browser: the outbound request is encrypted; the destination domain mimics a legitimate vendor; and the payload is small enough to resemble routine analytics traffic.
Why Code-at-Rest Scanners Miss It
Most website security tools fetch a page, analyze the HTML and JavaScript source, and flag known malicious signatures. Online card skimming evades this approach for a structural reason: the skimmer executes in a real user's browser, where the attacker can apply conditional logic that a scanner never triggers.
A script can return clean code to headless crawlers and activate only when it detects human behavior, a real IP address, or a specific geographic region. The merchant's WAF, origin server, and payment processor never receive any evidence of the theft. Only a monitoring layer that runs inside real visitor sessions can observe the script as it actually behaves.
Named Online Card Skimming Attacks
British Airways (2018). Attackers planted 22 lines of JavaScript on ba.com that exfiltrated payment data to a lookalike domain, baways[.]com. The script ran undetected for approximately two months and affected around 500,000 customers and staff. The UK Information Commissioner's Office issued an initial fine of £183 million under GDPR, later settled at £20 million. The case was one of the first high-profile GDPR enforcement actions tied directly to a client-side payment security failure.
Magecart (ongoing). The name originated from attacks targeting Magento-based shopping carts, but it now covers dozens of distinct threat actor groups using online card skimming across many platforms. Magecart actors have compromised third-party script providers whose libraries run on thousands of merchant sites simultaneously, turning a single supply-chain breach into a mass card-theft event. See the biggest Magecart attacks on record.
PCI DSS 4.0.1 Requirements for Card Skimming Prevention
PCI DSS 4.0.1 introduced two requirements that directly address online card skimming. Both became mandatory on March 31, 2025:
Requirement 6.4.3 mandates that every script loaded on a payment page be documented in an inventory, authorized with a business justification, and have its integrity protected. The intent is to prevent unauthorized scripts from running where card data is entered.
Requirement 11.6.1 mandates a tamper-detection mechanism that alerts on unauthorized changes to payment-page scripts and security-affecting HTTP headers, evaluated at least weekly or on a risk-analyzed schedule.
Manual script audits and point-in-time scans cannot satisfy these requirements at the volume and frequency they specify. Automated, continuous monitoring of what scripts actually do in real browsers is the baseline both requirements are written to enforce.
| Requirement | What it mandates | Mandatory since |
|---|---|---|
| 6.4.3 | Script inventory, authorization, and integrity on payment pages | March 31, 2025 |
| 11.6.1 | Tamper-detection with alerting for payment-page changes | March 31, 2025 |
How to Detect Online Card Skimming
Detection requires visibility into what scripts do inside real visitor browsers, not just what their source code looks like at scan time. cside deploys a single first-party JavaScript snippet (no proxy, no DNS changes) that monitors browser-level script behavior on every real page load.
The signals cside surfaces for online card skimming detection:
- New or modified scripts appearing on payment pages without authorization
- Unexpected listeners on input fields handling card data
- Outbound requests to domains outside an authorized allowlist
- Script behavior that differs between automated sessions and real-user sessions
This produces the continuous, real-time record PCI DSS 4.0.1 requires: an authorized script inventory for 6.4.3 and tamper-detection evidence for 11.6.1.
Related reading:
