TL;DR: what is online card skimming
- What card skimming is: JavaScript that reads card fields on checkout and beacons the data out before the form ever reaches your server.
- The damage is real: British Airways, Ticketmaster, Newegg, Warner Music, Segway. Per-incident losses routinely clear $100M once class actions land.
- Caught in the browser: You catch it in the browser session, not at the origin. The skimmer comes from an allowlisted domain and fires before submit.
Short on time? See cside's in-browser Magecart and skimmer blocking. It covers everything below in one deployment.
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:
- What is e-skimming?
- Formjacking vs Magecart vs digital skimming
- What are digital skimmers?
- PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 compliance guide
Notable online card-skimming incidents
The following disclosures are the reference cases whenever card skimming is discussed in a PCI DSS 4.0.1 or web-application-security context. Each involved malicious JavaScript on a merchant's checkout that captured card fields before they were sent for tokenisation.
- British Airways (2018). ~380,000 card records skimmed over 15 days from a compromised script on the checkout and mobile app. UK ICO fine reduced from £183M to £20M on appeal.
- Ticketmaster UK (2018). ~40,000 customers affected after the Inbenta customer-support widget served from a third-party CDN was modified to read the payment form.
- Newegg (2018). 15 lines of skimmer code ran on
checkout/payment.aspxfor 35 days, attributed to Magecart Group 4 by RiskIQ. - Warner Music Group (2020). Three-month compromise of multiple WMG storefronts on the Volusion platform.
- Segway (2022). Skimmer delivered through a malicious Magento extension, per Malwarebytes.
- Polyfill.io supply-chain (2024). After a change of ownership,
cdn.polyfill.ioserved malicious code to >100,000 sites embedding the library; Sansec's disclosure prompted Cloudflare, Fastly, and Google to intervene. - Adobe Commerce / Magento Cosmicsting (CVE-2024-34102, 2024). Server-side XML deserialisation bug used to plant client-side skimmers on hundreds of Magento merchants.
Each incident bypassed WAFs, network firewalls, and server-side controls because the skimmer executed in the shopper's browser, not on the merchant's server. That is the exact reason PCI DSS 4.0.1 introduced the browser-side controls in requirements 6.4.3 and 11.6.1.
