How to Spot and Stop E-Skimming Before It Hijacks Your Customers—and Your Credibility

Cybercriminals are increasingly targeting SMB e-commerce platforms through stealthy JavaScript injections on payment pages, also known as e-skimming. Recorded Future’s 2024 Fraud Intelligence Report shows a staggering 269 million card records exposed via dark and clear web sources in 2024 alone, with more than 11,000 unique e‑commerce domains infected—a nearly 300% year-over-year increase. Magecart-style digital skimming kits are making these attacks easy and rampant.

What if malicious code was siphoning customer payment data from your checkout page right now—and you didn’t know? This article offers a deep dive into what e‑skimming is, why it’s so dangerous, how PCI DSS v4.x addresses it, and some of the options available to help you.

What Is e‑Skimming—and Why It’s So Dangerous

E‑skimming, also known as web skimming, formjacking, or Magecart attacks, involves attackers injecting malicious JavaScript into a merchant’s payment pages. This hidden code captures sensitive customer data—card number, expiration date, CVV, billing info—in real time, directly from the browser.

Unlike traditional ATM skimmers, e‑skimmers are completely invisible to users and are usually undetected by standard defenses like web application firewalls. Transactions appear legitimate, so neither customers nor merchants realize the attack is happening.

Two Main Forms of Attack

1. Silent Skimming
   Malicious JavaScript scripts are stealthily embedded—often within trusted libraries or hosted as part of a third-party service (e.g., Google Tag Manager). These scripts quietly capture keypress or form input events and exfiltrate the data to attacker-controlled servers—all without any visible indicators or error messages on the site.
2. Formjacking/Double‑Entry Skimming
   Rather than overlaying scripts, attackers inject fake checkout forms or overlays that mimic the genuine one.  When the users submit their payment, the scammer harvests the data, then the payment data is sent to the scammer and the form displays an error like “Payment failed—please try again,” prompting a second entry. The second entry is the legitimate entry which is then processed.

Why This Threat Is So Potent

• Long Dwell Time: These attacks can go undetected for months. According to Source Defense, in 2024 alone, 269 million cards were compromised across roughly 11,000 e-commerce domains—a nearly 300% increase from 2023.
• Hidden in Plain Sight: These scripts piggy-back on legitimate third-party tools. For example, in early 2025, Magecart actors exploited Google Tag Manager to inject skimmers into Magento-based sites, making detection especially challenging.
• Browser-Level Access: A JavaScript skimmer running in a browser has unfettered access to all client-side elements, keys, and API endpoints—unlike backend systems that are typically scanned regularly.

For Attackers, It’s High Reward, Low Effort

Web skimming remains attractive to cybercriminals because it requires minimal effort to deploy yet can collect massive amounts of data over time. The stolen payment information is quickly sold on dark web marketplaces—making this a lucrative and low-risk operation for attackers. Victims often only learn of the breach after banks or credit monitoring services flag suspicious charges—when it’s already too late.

How Third‑Party Scripts Open the Door

Modern e‑commerce websites are built for convenience, speed, and personalization—but that often comes at a steep security cost. Nearly 98% of websites today rely on JavaScript, with an average of 18 scripts running per page. Of those, 40% execute directly on payment pages, where customer card data is entered.

These scripts power live chat, conversion tracking, A/B testing, personalization, marketing automation, and social media pixels. But every external script is a potential attack vector—especially when sourced from third parties with broad access across many merchant environments.

Magecart-style attackers specialize in exploiting these third-party connections. In 2024, a major campaign exploited CVE-2024-34102, nicknamed CosmicSting, to compromise Magento plug-ins and inject skimmers across hundreds of online stores. Other attackers targeted Google Tag Manager containers—trusted by millions of sites—to silently deliver card-harvesting scripts at checkout.

The danger is compounded by supply chain sprawl. A single vulnerable vendor, plug-in, or tag manager integration can lead to widespread, simultaneous compromises across entire merchant ecosystems. And because many of these scripts operate in the browser—outside traditional server-side visibility—they often go unmonitored and undetected for months.

In short: Your checkout page may look secure, but every unvetted script is a doorway—and attackers are walking right in.

PCI DSS v4.x Controls That Target e‑Skimming

The release of PCI DSS v4.x marks a significant shift in how merchants and service providers are expected to secure customer payment data—especially against client-side threats like e-skimming. Two new requirements stand out for e-commerce environments: 6.4.3 and 11.6.1.

Requirement 6.4.3 mandates that all scripts executing on payment pages must be:

• ‍Authorized — meaning approved and documented by the organization.
• ‍Integrity‑assured — using mechanisms like Subresource Integrity (SRI) hashes or Content Security Policy (CSP) headers to ensure the script hasn’t been tampered with.‍
• Inventoried and justified — with clear documentation of each script’s purpose, source, and function.

Requirement 11.6.1 adds another layer of defense by requiring merchants to deploy tamper detection systems. These systems must monitor changes to scripts and HTTP headers on payment pages at least once per week, with real-time alerts for unauthorized modifications.

Together, these controls are designed to shift visibility and accountability to the browser level—where most e-skimming attacks happen. By formalizing script management and enforcing ongoing change detection, PCI DSS v4.x closes long-standing blind spots in the e-commerce security stack.

Compliance isn’t optional—these requirements became mandatory after March 31, 2025, for SAQ A-EP and SAQ D merchants.

Understanding Your Setup: The Questions That Determine Your Risk

When it comes to PCI DSS compliance—and your vulnerability to e‑skimming—how your e‑commerce website is architected matters more than most merchants realize. Many SMBs assume that outsourcing to a website builder or using a plug-and-play checkout solution automatically reduces their PCI burden. In reality though, the structure of your payment page defines your scope, your obligations, and your exposure.

If your site uses an iFrame or a URL redirect to offload payment data entry to a third-party provider, you may be eligible for the simplified SAQ A form. But if any scripts run client-side—on the same page where customers enter their card details—then you likely fall into SAQ A‑EP or SAQ D, which carries heavier security requirements under PCI DSS v4.x.

That’s why we encourage merchants to ask smarter questions of their web teams and third-party providers:

• Does your checkout page include third-party scripts (analytics, chat, personalization tools)?
• Who monitors changes to those scripts?
• Is your e-commerce platform or SaaS provider a PCI DSS compliant service provider with a valid Attestation of Compliance?
• Do they maintain a PCI responsibility matrix?

If you are unsure of the answers to these questions, push for clear answers from your web teams and third-party providers to ensure your e-commerce site is safe.

The bottom line: clarity on your setup is step one. Without it, you’re navigating blind through complex compliance terrain—and attackers are counting on that.

Before the Breach Happens, Take Control

E‑skimming is not a hypothetical threat—it’s a present and growing danger quietly targeting e-commerce sites of all sizes. These attacks don’t trigger alarms or display warning signs. They sit silently inside browsers, harvesting cardholder data as if nothing’s wrong. And if your payment page runs any client-side scripts today, your site may already be vulnerable.

VikingCloud is here to help. Whether you’re unsure of your SAQ scope, struggling to inventory your scripts, or need support implementing PCI DSS v4.x controls, we offer the guidance and technical support to make it manageable—and effective. Reach out to a member of our team for more information!

For more details on this topic, also take a look at “The Hidden Threat: Unraveling E-Skimming, Script Security, and PCI DSS Compliance” webinar.