The checkout is the most sensitive page of any online shop: this is exactly where customers enter their card number, address and payment details - and exactly where Magecart groups strike. In so-called web skimming, attackers inject a few lines of JavaScript into the payment page that silently read every entry and send it off to a foreign domain. The number of attacks is rising: security researchers now record around 30 new skimmer signatures per day (Sansec). This article shows how a skimmer reaches the checkout, how to spot a compromise and how to protect the integrity of your payment page for the long term with a script inventory, Content Security Policy and Subresource Integrity.
What Magecart and Web Skimming Actually Are
Magecart is not a single tool but an umbrella term for numerous criminal groups that have been stealing payment data directly from buyers' browsers for about a decade. The method is called web skimming or formjacking: attackers place tampered JavaScript on the checkout or payment page that reads the entered card and address data in real time and sends it to a server they control. The term alludes to the classic card readers on ATMs - only here the capture is purely digital and completely invisible to the customer.
The decisive difference from many other attacks is that web skimming is a client-side attack. The malicious code does not run on your server but in the visitor's browser. A server-side virus scan or a firewall often notices nothing, because the actual data exfiltration only happens on the customer's device. That is precisely why skimmers often remain undetected for weeks or months: in a campaign uncovered in January 2026, a skimming network had been active unnoticed since 2022 and harvested cards across six major payment networks (Silent Push/Malwarebytes).
The payment page is naturally where personal and financial data converge. A single compromised script is enough to grab the card number, expiry date and security code on every purchase. Because modern shops embed numerous third-party scripts - analytics, chat, tag managers, payment SDKs - each additional inclusion enlarges the checkout's attack surface.
Why the Threat Is Growing Sharply in 2026
Web skimming is no longer a marginal phenomenon but an industrially run business model. Attack figures have risen markedly. The security provider Sansec adds an average of 30 new skimmer signatures to its scanner every day (Sansec) - a measure of how quickly attackers vary and disguise their malicious code. For 2025, more than 10,500 active skimming infections were counted, through which more than 23 million transactions were compromised (Recorded Future).
The increase has several causes. First, shops increasingly rely on third-party scripts that are hard to remove from day-to-day operations - each of these inclusions is a potential entry point. Second, skimming kits are cheap to obtain and easy to operate. Third, the attacks are becoming technically more sophisticated: campaigns hide their code in invisible graphics, imitate legitimate payment providers or use foreign cloud infrastructure as cover. Anyone keeping an eye on the Cyber Resilience Act and its obligations quickly sees that product security goes beyond mere server configuration.
A compromised checkout costs more than stolen card data. Add chargebacks, possible penalties from payment providers, notification duties under the GDPR and - often most expensive - the loss of customer trust. Because skimmers tend to remain undetected for a long time, the damage accumulates over the entire duration of the infection.
How a Skimmer Reaches the Checkout
An effective defense begins with understanding the entry points. In practice, attackers keep using the same routes to place their malicious code on the payment page:
- Compromised third-party scripts: analytics tools, chat widgets, tag managers or ad snippets are loaded from an external domain. If the provider or the delivered script is tampered with, the skimmer reaches your shop without any break-in of its own. In a campaign in April 2026, attackers hid the malicious code in invisible SVG elements and injected a fake checkout overlay on 99 shops that exfiltrated data to six attacker domains (Sansec).
- Outdated shop software and unpatched extensions: known vulnerabilities in old versions or plugins are a standard entry point. Through a single vulnerability, 471 shops were compromised in just one hour in March 2026 (Sansec). Anyone still running an end-of-life version should not postpone the migration away from Shopware 5.
- Stolen credentials and supply chain: captured administrator passwords or a tampered dependency make it possible to inject code directly. Supply-chain attacks hit many shops at once with a single blow.
- Faked payment infrastructure: some campaigns abuse the names and interfaces of real payment services to appear legitimate. One skimmer network ran more than 4,800 fake shop storefronts on .shop domains that imitated well-known brands (Sansec).
It is striking that many of these routes require no direct break-in to the shop server at all. The skimmer arrives via a third-party system - and then lives in the customer's browser. That is exactly why classic, purely server-side defenses fall short here.
| Entry point | Typical example | Why it is hard to detect |
|---|---|---|
| Third-party script | Analytics or chat widget | Loads from external domain, changes unnoticed |
| Old software | Unpatched plugin | Vulnerability public, exploitation automated |
| Supply chain | Tampered dependency | Hits many shops at once |
| Fake payment page | Imitated payment SDK | Looks completely legitimate to customers |
Warning Signs: How to Spot a Compromised Checkout
Because the malicious code runs in the browser, monitoring the delivered page is decisive. A pure server scan is not enough, because the malicious third-party script often does not sit on your server at all. These signals point to a compromise:
- Unexpected outbound connections: the payment page contacts an unknown domain that was never embedded before.
- Changed script contents: the checksum (hash) of an embedded script suddenly deviates from the approved version.
- New or unknown script tags in the checkout source code that no one deliberately added.
- Content Security Policy violations appearing in the browser or in your logs.
- A cluster of fraud reports: customers report fraudulent card charges shortly after their purchase. A systematic fraud detection approach makes such patterns visible earlier.
A file integrity check on the server detects changes to your own files - but not to a script that is loaded from a foreign domain and tampered with there. The checkout therefore needs monitoring of the page as it is actually delivered in the browser, reporting changes to scripts and page content.
Protection with a Script Inventory, CSP and SRI
No single measure defeats web skimming; it takes an interplay of several building blocks. They all pursue the same goal: only explicitly approved scripts may run in the checkout, and any unauthorized change stands out immediately.
Script inventory
A documented list of all scripts loaded on the payment page - with a justification for why each one is needed. Anything not on the list has no business in the checkout.
Content Security Policy
A CSP header defines which domains scripts may be loaded from and to which destinations data may be sent. A skimmer trying to exfiltrate to a foreign domain is thus blocked by the browser.
Subresource Integrity
With an SRI hash the browser checks whether an external script exactly matches the approved version. If the file was tampered with, the browser refuses to execute it.
Tamper monitoring
Ongoing monitoring of the payment page reports as soon as scripts, HTTP headers or page content change without authorization - the prerequisite for detecting an incident quickly.
Content Security Policy and Subresource Integrity are standard mechanisms in modern browsers and can be introduced step by step. Careful maintenance matters: if a payment provider changes its script, the stored hash must be updated with it. In the programming and development of your shop, these rules therefore belong firmly in the release process. An example of a restrictive policy and an inclusion secured by hash:
<!-- CSP header: only own and explicitly allowed sources -->
<!-- Content-Security-Policy:
default-src 'self';
script-src 'self' https://js.paymentprovider.example;
connect-src 'self' https://api.paymentprovider.example -->
<!-- External script secured via Subresource Integrity -->
<script src="https://js.paymentprovider.example/checkout.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K9dEXamplEhaSh"
crossorigin="anonymous"></script>It also helps to keep the number of third-party scripts fundamentally small. Every script that is not loaded cannot be compromised either. Anyone who trims their shop of unnecessary third-party scripts improves both the load time and the security of the checkout at the same time.
PCI DSS 6.4.3 and 11.6.1: Checkout Integrity Is Mandatory
Protecting the payment page is not just a good idea but, for merchants that process card data, a binding requirement. The security standard PCI DSS 4.0 introduced two new requirements for this that have been mandatory since 31 March 2025 (PCI SSC).
| Requirement | What it demands | Goal |
|---|---|---|
| 6.4.3 | Inventory and integrity of all payment-page scripts | Only authorized scripts run |
| 11.6.1 | Detection of tampering with the page and HTTP headers | Changes stand out at once |
Requirement 6.4.3 demands that every script executed on the payment page is authorized, that its integrity is assured and that a complete, justified inventory of all scripts is maintained (PCI SSC). Requirement 11.6.1 demands a mechanism that detects and reports an unauthorized change to the payment page as received in the browser or to its HTTP headers - and that runs at least once every seven days (PCI SSC). One rule defines the target state, the other watches for deviation from it.
Many shops embed payment fields as elements provided by a service to reduce their own effort. That lowers the risk but does not remove it: the skimmer can manipulate the surrounding page, inject a fake overlay or redirect the customer to a rebuilt input. That is why PCI DSS requires monitoring of the entire payment page, not just the input fields (PCI SSC).
A Defense Concept Step by Step
The individual building blocks become resilient protection when they are implemented in a fixed order and maintained continuously. The following sequence has proven itself in practice:
- Inventory: record all scripts on checkout and payment pages and justify for each entry why it is needed.
- Minimize: remove scripts that are no longer needed or duplicated and deliberately keep the number of external inclusions small.
- Introduce CSP: set a restrictive Content Security Policy that only allows approved sources for scripts and data destinations.
- Set SRI: secure external scripts with a Subresource Integrity hash and update the hash with every change.
- Monitor: set up tamper monitoring that reports changes to scripts and page content in the delivered state.
- Patch: keep the shop system and extensions up to date; an experienced Shopware agency can roll out updates in a planned and tested manner.
- Respond: define a procedure for an emergency - from isolating the payment page to a clean restore from a tested backup.
No single step replaces the others. Only the interplay of reduction, rules and monitoring makes the checkout resilient. And because attacks and embedded services change constantly, security is not a one-off project but an ongoing operational process - comparable to the continuous shop monitoring for availability and performance.
Anchoring Checkout Security in Operations Now
Web skimming does not only hit big brands - on the contrary, smaller shops become targets because they less often have their own security processes. The good news is that the checkout can be hardened significantly with manageable, proven measures. What matters is that the script inventory, CSP, SRI and monitoring are firmly anchored in day-to-day operations and do not fizzle out as a one-time action.
Checkout hardening in hosting
In the hosting and maintenance by XICTRON, we anchor CSP, SRI and a maintained script inventory directly in the ongoing operation of your shop.
Payment-page monitoring
Tamper monitoring reports unauthorized changes to scripts and page content - in line with the requirements of PCI DSS 11.6.1 (PCI SSC).
Up-to-date software
Regular updates and patches close known vulnerabilities before they are exploited automatically - a core risk according to current analyses (Sansec).
A prepared emergency
A documented incident procedure, interlocked with fraud detection and a tested backup, noticeably shortens the response time.
Whether a tampered third-party script, an outdated extension or a fake payment page: what matters is that the integrity of your checkout is checked continuously, before card data is lost. Automated and regulatory checks are increasing as well - anyone who takes technical diligence seriously is also better prepared for reviews such as the automated BFSG scan. We review the current state of your payment page, set up CSP, SRI and a script inventory and establish appropriate monitoring. Talk to our team to set up your shop's checkout security in a planned way.
This article draws on threat analyses by Sansec (rise in Magecart attacks, new skimmer signatures daily, fake .shop storefronts, SVG overlay and PolyShell campaigns in 2026), investigations by Silent Push and Malwarebytes (skimming network active since 2022), the analysis by Recorded Future (active skimming infections and compromised transactions in 2025) and requirements 6.4.3 and 11.6.1 from PCI DSS 4.0 by the PCI Security Standards Council, mandatory since 31 March 2025. The figures cited may change over time and serve as guidance; this article does not replace individual security or legal advice. As of August 2026.
In web skimming, attackers inject tampered JavaScript into a shop's checkout or payment page. This script reads the entered card and address data in real time and sends it to a foreign server. Magecart is the umbrella term for the criminal groups that carry out such attacks. Because the code runs in the customer's browser, server-side defenses often do not notice the attack.
Web skimming is a client-side attack: the malicious code runs in the visitor's browser, not on your server. Often the malicious script even sits on a foreign domain, such as a tampered analytics or payment script. A server-side file integrity check does not detect such changes. What is needed is monitoring of the payment page as it is actually delivered in the browser.
A Content Security Policy defines which domains scripts may be loaded from and to which destinations data may be sent. If a skimmer tries to exfiltrate data to a foreign domain, the browser blocks it. Subresource Integrity adds a cryptographic checksum: the browser only executes an external script if it exactly matches the approved version. Both mechanisms act directly in the browser and complement ongoing monitoring.
Requirement 6.4.3 demands an inventory of all payment-page scripts, a justification per script and assurance of their integrity. Requirement 11.6.1 demands a mechanism that detects unauthorized changes to the payment page and its HTTP headers and runs at least once every seven days (PCI SSC). Both have been mandatory for affected merchants since 31 March 2025 and together aim at the integrity of the checkout.
Embedded payment fields from a service provider reduce the risk but do not remove it. A skimmer can manipulate the surrounding page, inject a fake overlay or redirect customers. That is why the monitoring obligation under PCI DSS applies to the entire payment page, not only to the input fields. A hardened and monitored page therefore typically remains necessary even with outsourced payment fields.
We record the scripts loaded on your payment page, remove unnecessary inclusions and set up a restrictive Content Security Policy as well as Subresource Integrity hashes. In addition, we establish monitoring that reports changes to the delivered page and keep the shop system and extensions up to date. This way, checkout security can typically be organized as a permanent part of ongoing operations rather than improvised damage control.