Category: Incident Response and Skimming
Web Skimming
Also known as: Magecart attack, Formjacking, Web skimmer attack
Simply put
Web skimming is a type of cyberattack in which criminals secretly insert malicious code into a website to steal information that customers enter, such as payment card details. It often targets the checkout or payment pages of online stores, capturing data as shoppers type it into web forms. It is sometimes called a Magecart attack or formjacking.
Formal definition
Web skimming, also referred to as a Magecart attack or formjacking, is a client-side attack in which an adversary injects malicious code, typically JavaScript, into a website or its dependencies and exfiltrates data submitted through HTML forms. The injected skimmer commonly harvests data entered on payment or checkout pages, including payment card details, and transmits it to attacker-controlled infrastructure. Because the theft occurs in the browser as data is entered, it can capture cardholder data and any sensitive authentication data (such as CVV2/CVC2/CID) present in the form regardless of server-side storage controls; note that specific detection and control effectiveness depends on implementation and validation.
Why it matters
Web skimming is significant because it captures payment data at the point where a customer types it into a web form, inside the browser, before server-side protections apply. This means that even where a merchant follows storage controls for cardholder data, a skimmer can still harvest the data as it is entered, including sensitive authentication data such as CVV2/CVC2/CID that must not be stored after authorization. The attack undermines the assumption that securing back-end systems is sufficient, because the theft occurs client-side.
The risk is compounded by the modern web supply chain. Checkout pages routinely load third-party JavaScript for analytics, tag management, chat, and payment functionality, and any of these dependencies can become the injection point for malicious code. Because the same skimmer may target businesses connected to major payment networks across long-running campaigns, a single compromised script or vendor can affect many merchants at once, and the malicious code can persist undetected while continuing to exfiltrate data.
For compliance and security teams, web skimming illustrates why controls governing scripts on payment pages and monitoring for unauthorized changes to those pages are relevant to protecting cardholder data. The exact detection and control effectiveness depends on implementation and validation rather than on the presence of any single control, and readers should confirm applicable requirements against the current published PCI DSS standard rather than assuming fixed requirement numbers.
Who it's relevant to
E-commerce merchants and site operators
Merchants running online checkout pages are the primary targets, since skimmers harvest data entered into their payment forms. Operators should be aware that third-party scripts loaded onto checkout pages expand the attack surface and that server-side storage controls do not protect data captured client-side.
Security engineers and application security teams
Teams responsible for web application integrity need to account for the injection of malicious JavaScript into pages or their dependencies. Monitoring for unauthorized changes to scripts on payment pages is relevant, though detection effectiveness depends on implementation and validation.
Compliance and PCI DSS assessors
Because web skimming can capture cardholder data and sensitive authentication data at entry, it is relevant to how controls over scripts on payment pages are assessed. Confirm applicable requirements and their current wording against the published PCI DSS standard rather than assuming fixed numbering.
Fraud analysts and payment risk teams
Web skimming is a source of stolen card-not-present data that can later fuel fraudulent transactions. Analysts tracking long-running campaigns, including those targeting businesses connected to major payment networks, may find skimming a relevant upstream cause of downstream fraud patterns.
Third-party and supply-chain vendors
Providers of analytics, tag management, and other embedded scripts can become the injection point for skimmers. A compromise of a single vendor script may affect many merchants that load it, making vendor code integrity a shared concern.
Inside Web Skimming
Client-Side Payment Page Compromise
Web skimming (often called Magecart-style attack or e-skimming) involves injecting malicious code into the payment page or checkout flow rendered in the customer's browser, allowing attackers to capture cardholder data and, in many cases, sensitive authentication data such as CVV2/CVC2/CID as it is entered. Because sensitive authentication data must not be stored after authorization, its interception at entry is a significant exposure.
Malicious JavaScript Injection
The core mechanism is unauthorized script that reads form fields, keystrokes, or DOM elements on the payment page and exfiltrates the data to an attacker-controlled endpoint. The injection may target the merchant's own hosted scripts or the browser rendering environment directly.
Third-Party and Supply-Chain Script Risk
Many skimming incidents originate from compromised third-party scripts (analytics, chat widgets, tag managers, content delivery resources) loaded into the payment page. This makes the client-side software supply chain a key part of the attack surface.
Data Exfiltration Channel
Captured data is transmitted from the browser to an external collection server, sometimes disguised to resemble legitimate traffic. The exfiltration may be intermittent or conditional to evade detection.
Relationship to PCI DSS Scope
Payment pages and the scripts they load are relevant to PCI DSS. Recent versions of PCI DSS introduced requirements addressing the management and integrity monitoring of scripts on payment pages and the detection of changes to HTTP headers and page content; readers should confirm the specific requirement wording and applicability dates against the current published standard rather than assuming a fixed requirement number.
Common questions
Answers to the questions practitioners most commonly ask about Web Skimming.
Is web skimming the same as a physical card skimmer placed on a POS terminal or ATM?
No. Web skimming, sometimes called e-skimming or Magecart-style attacks, targets the client-side code or payment page of an e-commerce site to capture cardholder data and, where present, sensitive authentication data such as CVV2/CVC2/CAV2/CID entered by the customer. Physical skimmers are hardware devices that capture card-present data, including full track data, at a physical terminal or ATM. Both aim to steal payment data, but they operate in different channels: web skimming is a card-not-present threat affecting the checkout flow, while physical skimming is a card-present threat. The controls that help mitigate each also differ.
Does using a third-party or iframe-hosted payment page mean my site cannot be affected by web skimming?
Not necessarily. Redirecting or embedding a payment form via a third party can reduce the exposure of your own pages, but it does not by itself eliminate the risk. Attackers may still compromise the surrounding merchant page to overlay a fake form, manipulate scripts that load before the redirect, or tamper with the integrity of the page that references the payment provider. The effect on your risk and on PCI DSS scope depends on how the integration is implemented and validated, not on the label of the method alone. You should confirm your specific responsibilities and the applicable requirements against the current published PCI DSS.
What controls help detect or mitigate web skimming on a payment page?
Controls that may help include maintaining an inventory of scripts loaded on payment pages, authorizing scripts before use, and monitoring for unauthorized changes to script content or behavior. Content Security Policy and Subresource Integrity can help constrain and verify what executes in the browser, though their effectiveness depends on correct configuration and coverage. File integrity monitoring, change detection, and review of third-party and fourth-party dependencies also contribute. No single control should be treated as complete; each has limitations and can produce false positives or miss obfuscated or dynamically injected code. Confirm the applicable script and page-monitoring requirements against the current published PCI DSS version, as wording and numbering differ between versions.
How does managing third-party scripts on the checkout page relate to web skimming risk?
Payment pages often load scripts from external providers such as analytics, tag managers, chat, and advertising services, and those providers may in turn load additional code. Each dependency is a potential injection point if compromised. Practices that may reduce this risk include limiting scripts on payment pages to those that are necessary, documenting and authorizing each script and its purpose, and monitoring for changes to the scripts and their sources. Because you may not directly control the code your third parties serve, contractual and monitoring measures both play a role. The specific expectations for justifying and monitoring page scripts are addressed in the current PCI DSS; verify the exact requirements and applicability for your environment.
Where in my environment should I focus web skimming defenses?
Focus on the pages that receive account data as entered by the consumer, since these are where a client-side skimmer can capture cardholder data and, if collected, sensitive authentication data such as the card verification value. Consider the integrity of the web server delivering those pages, the build and deployment pipeline that publishes them, the content delivery infrastructure, and every script and third-party dependency the payment page invokes at runtime. Because skimming executes in the customer's browser, defenses that only inspect server-side storage may not detect it. Determine the scope of the affected pages and the corresponding requirements against the current published standard rather than assuming a fixed set.
How does web skimming interact with tokenization or a hosted payment field approach?
Tokenization and hosted or isolated payment fields are intended to reduce where clear cardholder data appears in your systems, which can lower exposure and may affect PCI DSS scope depending on implementation and validation. However, these measures act on how data is stored or where it is captured, and they do not inherently stop client-side code injected into the page that surrounds or interacts with the input fields. An attacker who alters the merchant page could still attempt to intercept data before or as it is entered. Treat tokenization and hosted fields as complementary to, not a replacement for, script integrity monitoring and change detection, and validate the resulting scope against the current published PCI DSS.
Common misconceptions
TLS/HTTPS on the checkout page prevents web skimming.
Transport encryption protects data in transit between the browser and server, but web skimming captures data within the browser before or as it is submitted. A page served over HTTPS can still run malicious injected script, so TLS is intended to protect the channel and does not address client-side code integrity.
Using a hosted payment page or iframe from a service provider fully eliminates web skimming exposure for the merchant.
Redirects and iframes can reduce the merchant's direct exposure, but risk may remain depending on implementation—for example, if the surrounding page or its scripts can manipulate the payment fields, or if the third-party components themselves are compromised. The effect on PCI DSS scope depends on implementation and validation, not on the label alone.
If cardholder data is tokenized after submission, skimming is not a concern.
Tokenization transforms data after it is received, but web skimming intercepts data at the point of entry in the browser, before tokenization occurs. Tokenization and skimming controls address different points in the data flow and are not substitutes for each other.
Best practices
Maintain an inventory of all scripts loaded on payment pages, authorize each one, and monitor them for unexpected changes or additions, consistent with current PCI DSS expectations for payment page script management and integrity monitoring.
Apply integrity controls such as Subresource Integrity where feasible and monitor HTTP headers and page content for unauthorized modification, recognizing these help reduce but do not guarantee elimination of tampering.
Minimize third-party and supply-chain scripts on checkout pages, vet providers, and isolate payment fields from non-essential code to limit the client-side attack surface.
Consider architectural approaches such as hosted fields or iframes that constrain where cardholder data and sensitive authentication data are entered, validating the actual scope and residual risk of the chosen implementation rather than relying on the design label.
Deploy content security policies to restrict which origins can execute scripts and to which endpoints data may be sent, tuning to balance protection against false-positive breakage of legitimate functionality.
Establish detection and response processes for anomalous outbound requests from payment pages, and confirm all applicable controls against the current published PCI DSS version, since requirement wording and applicability dates vary between versions.