An online shop can work flawlessly, load fast and still hand every order's card details to criminals in the background. That is exactly what web skimming does, often named after the best-known attacker group, Magecart: attackers inject a few lines of JavaScript into the checkout page that read the payment fields in the customer's browser and send them to a foreign domain. The insidious part is the location of the attack. The malicious code runs client-side in the browser, not on the server -- so it bypasses classic server-side malware scans and often deletes its own traces after the theft. Exploitation of vulnerabilities was recently the initial access vector in 20 percent of breaches, a rise of 34 percent over the prior year (Verizon DBIR, 2025). Because such a skimmer can stay active for months -- a breach is identified and contained after an average of 241 days (IBM Cost of a Data Breach, 2025) -- the payment card standard has responded: since 31 March 2025, a script inventory and tamper detection at the checkout are mandatory (PCI Security Standards Council, 2025). This article shows how a third-party script inventory, Subresource Integrity, a restrictive Content Security Policy and continuous monitoring of your checkout scripts stop web skimming -- and why that is something different from server-side malware scanning.
Key takeaways
- Web skimming runs client-side in the browser: the skimmer reads the payment fields right in the checkout and sends them to a foreign domain -- server-side malware scans see nothing of this.
- A complete inventory of all third-party scripts on the payment page is the foundation: you can only secure what you know (PCI DSS 4.0, requirement 6.4.3).
- Subresource Integrity binds external scripts to a hash, a Content Security Policy allows only approved sources -- the browser blocks tampered or foreign scripts.
- Tamper detection checks at least every seven days whether scripts or HTTP headers of the payment page were changed without authorization (PCI DSS 4.0, requirement 11.6.1).
- Continuous change and integrity monitoring turns a manipulation that would otherwise go unnoticed for months into an alert within minutes.
How Web Skimming Works at the Checkout
Web skimming rarely begins at the payment page itself, but at a vulnerability before it. Typical entry points are a vulnerable plugin, a hijacked editor or admin account, or a tampered third-party script loaded via a content delivery network. 88 percent of basic web application attacks used stolen credentials (Verizon DBIR, 2025) -- a single leaked admin login is enough to write malicious code into the checkout page template. Once the skimmer is in place, it runs along in every customer's browser: it attaches to the input fields for card number, expiry date and security code, reads the values on entry or submission and sends them via an inconspicuous image request or fetch to an attacker's server.
Modern skimmers are optimized for stealth. Many load their malicious code only on the payment page and only for real visitors, not for administrators or known analysis tools. Others obfuscate the code multiple times, disguise the exfiltration domain as a seemingly harmless analytics or font address and remove themselves from the page after a successful theft. It is precisely this self-deletion that makes later forensics hard -- and it is why a single snapshot rarely suffices and only continuous observation of the delivered page reliably triggers.
The Skimmer Deletes Its Traces
Why Server-Side Malware Scans Miss Skimmers
Server-side malware scanning is important and finds backdoors, web shells and altered PHP files -- but against web skimming it is at a structural disadvantage. A scanner on the server checks files and the database on the host. A skimmer, however, often only takes shape in the browser: it can be loaded via an externally included script that does not reside on your own server at all, or it can activate only under certain conditions that a server scan hardly triggers. That is why we deliberately separate the two layers. How a thorough server-side malware scan is built we cover elsewhere; here it is about the client-side defense that engages exactly where the skimmer works. The payment card standard draws the same line and, in requirement 11.6.1, explicitly requires detection of changes to the scripts and HTTP headers delivered in the browser (PCI Security Standards Council, 2025).
| Aspect | Server-side malware scanning | Client-side script integrity |
|---|---|---|
| Checks | Files and database on the server | Scripts and headers delivered in the browser |
| Finds | Backdoors, web shells, injected PHP files | Skimmers, tampered and foreign scripts |
| External scripts | Not covered (not on the server) | Secured via SRI and CSP |
| Conditional malicious code | Often not triggered | Becomes visible on a real page load |
| PCI DSS 4.0 | Complementary base hygiene | Requirements 6.4.3 and 11.6.1 |
| Role | Protects the server | Protects the payment page |
Two Layers, Not Two Alternatives
Third-Party Script Inventory: The Foundation of 6.4.3
You can only protect what you know. That is why every checkout hardening begins with a complete inventory of all scripts loaded on the payment page and the pages leading up to it. Requirement 6.4.3 of the payment card standard demands exactly this: every script on the payment page must be authorized, integrity-assured and carry a documented justification for its use (PCI Security Standards Council, 2025). In practice this inventory is regularly surprising -- a typical shop loads, besides its own scripts, payment widgets, chat tools, consent managers and analysis libraries, often with further, lazily loaded dependencies that nobody consciously included any more.
- Capture all script sources: own and external, statically included and dynamically loaded, including the scripts inside payment and consent widgets.
- Assign an owner to each source: who operates it, what purpose does it serve, is it really needed for the checkout?
- Remove scripts that are not needed: anything not required on the payment page does not belong there -- the smallest attack surface is the best.
- Secure the remaining scripts: bind them to a hash via Subresource Integrity and explicitly allow them in the Content Security Policy.
- Version the inventory: with every deploy and every change to third-party scripts, the list is updated and re-approved.
This inventory is not a one-off document but lives with the shop. Every update can introduce new scripts, every third-party widget can change its included files without warning. We therefore maintain the script inventory as a fixed part of ongoing Shopware maintenance and combine it with a regular plugin and script audit so that the list of approved scripts and the scripts actually delivered do not drift apart.
Subresource Integrity and Content Security Policy
Once the scripts are inventoried, the two central browser mechanisms follow. Subresource Integrity (SRI) attaches a cryptographic hash to every externally included script. The browser executes the script only if its content matches this hash exactly -- if an attacker changes the file by even one character, the browser refuses execution. The Content Security Policy (CSP) additionally defines which sources scripts may be loaded from at all and where the page may send data. A skimmer that wants to send card data to a foreign domain fails against a restrictive connect-src rule, even if it managed to inject code.
<!-- Bind an external script to an integrity hash (SRI) -->
<script src="https://cdn.example.com/widget.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6R9GqQ8Kuxy9rx7HNQlGYl1kPzQho1wxYawnHQ8w"
crossorigin="anonymous"></script>
# Restrictive Content Security Policy as an HTTP header
Content-Security-Policy:
default-src 'self';
script-src 'self' https://cdn.example.com 'nonce-Rk9PMjAyNg';
connect-src 'self' https://pay.example.com;
object-src 'none';
base-uri 'self';
report-uri /csp-reportSubresource Integrity
Binds every external script to a hash. If the content deviates, the browser blocks execution -- so a tampered CDN file becomes ineffective.
Content Security Policy
Allows scripts only from approved sources and limits the target domains for outgoing data. Injected code can then send nothing outward.
Both mechanisms have limits you need to know. SRI works reliably for statically versioned files, less so for scripts that legitimately change on every request -- these need a CSP with nonce or hash and a contractually assured provider. A CSP, in turn, only takes effect if it is kept restrictive and consistently maintained; a policy weakened with unsafe-inline offers little protection. That is why CSP maintenance and the application of security updates belong together, complemented by an upstream WAF and bot protection that catches known attack patterns before they reach the application. Around 78 new vulnerabilities become known every day, a rise of 14 percent over the prior year (BSI security report, 2024) -- today's rules rarely fit tomorrow's threats unchanged.
Tamper Detection per PCI DSS 4.0
Inventory, SRI and CSP reduce the likelihood of a successful manipulation but do not fully rule it out. That is why requirement 11.6.1 additionally demands active monitoring: a mechanism that detects unauthorized changes to the scripts and the security-relevant HTTP headers of the payment page and checks at least every seven days (PCI Security Standards Council, 2025). In practice this means regularly comparing the state of the checkout page actually delivered in the browser against an approved reference state -- the script list, the content hashes and the headers. Any deviation triggers an alert.
What Tamper Detection Checks
The seven-day threshold is the minimum, not the goal. With an attack pattern in which 70 percent of exploitation attempts lead to a full intrusion and 68 percent end in executed malicious code (ENISA Threat Landscape, 2025), seven days is a long time for a skimmer to harvest cards undisturbed. A much tighter interval, up to continuous checking, is advisable -- along with a prepared incident plan for the worst case so that an alert is followed by structured steps rather than panic. Exploitation of vulnerabilities was recently the second most common initial access at 21.3 percent of European incidents (ENISA Threat Landscape, 2025).
Four Layers of Checkout Protection
1. Script inventory
A complete, versioned list of all scripts on the payment page with purpose and ownership -- the foundation per requirement 6.4.3.
2. Subresource Integrity
Every external script bound to a hash. Changed files are not executed by the browser.
3. Content Security Policy
Only approved script sources, strictly limited target domains for outgoing data. Injected code runs into the void.
4. Tamper detection
Continuous comparison of the delivered page against the reference state with an alert on every deviation -- requirement 11.6.1.
None of these layers is sufficient on its own, but together they form a layered defense that matches the PCI requirements. This matters especially for smaller merchants: 80 percent of reported attacks targeted small and medium-sized enterprises (BSI security report, 2024), which often lack the resources for lasting monitoring. Checkout security is thus not a one-off project but an ongoing task -- just as the accessibility of the shop under the BFSG or the deliverability of shop emails via DMARC are part of continuous maintenance.
Continuous Change and Integrity Monitoring
The most effective lever against web skimming is time -- more precisely: taking it away from attackers. A skimmer does more damage the longer it stays unnoticed, and the baseline is uncomfortable: only about 54 percent of critical vulnerabilities in exposed systems were fully remediated, at a median of 32 days (Verizon DBIR, 2025). A weekly or even manual glance rarely suffices against this. Continuous change and integrity monitoring observes the checkout scripts, the content hashes and the HTTP headers on an ongoing basis and raises an alert on every unauthorized change -- long before a skimmer can harvest a meaningful number of cards.
Web skimming thrives on unobserved time. Whoever monitors the checkout scripts continuously turns a months-long data leak into an alert within minutes.
This is exactly where our continuous change and integrity monitoring comes in: we build the script inventory, set up Subresource Integrity and a restrictive Content Security Policy, define the reference state of the payment page and monitor it continuously against unauthorized changes -- together with structured patch and CVE management that closes the most common entry points. The average total cost of a data breach was recently 4.44 million US dollars worldwide (IBM Cost of a Data Breach, 2025); for smaller shops the figure is lower, yet lost revenue, ranking loss, possible fines and loss of trust remain. Against this stands a fraction of that sum for ongoing monitoring. As part of an SLA maintenance contract and our full managed maintenance services, checkout hardening thus turns from a compliance obligation into a quiet, traceable process in the background.