When people think of data breaches, they usually think of a person hacking a server and stealing a database. Card skimming, however, is not that. Card skimming occurs in the user’s browser, specifically on the checkout screen, and cannot be traced by your server logs.
The way it works is that a snippet of malicious JavaScript is placed on your checkout page, where it records information entered by customers and sends it to a server controlled by the hacker. The fact that the transaction still goes through means that neither you nor the customer knows that something has gone wrong, and this raises two questions: how did the code get onto the page, and what can you do to stop it?
Attackers hardly need to hack your site directly. Most of the time, they’ll get in through a third-party script your page already loads. That could be an analytics tag, a chat widget, or an A/B testing tool. Every time a customer hits your checkout, these scripts pull fresh code from external servers. If an attacker compromises the vendor behind one of those scripts, they can put skimming code into the file your page is already trusting and loading without question.
Direct compromise is the other way in. If someone gets access to your CMS or deployment pipeline, they can just edit the checkout template and drop the script in themselves. Whichever route is used, the page will look and behave exactly the same as it always did, which is what makes this so difficult to catch.
A reputable payment provider’s iframe will protect the form itself. That’s actually true. But your checkout page still loads other scripts around that iframe, and if any of those surrounding scripts are compromised, an attacker can overlay a fake form on top of the actual one. They can also capture keystrokes before the data ever reaches the secure iframe.
Your server-side security tools won’t help here either. A web application firewall inspects traffic arriving at your server, but the skimmer runs completely inside the customer’s browser and never touches your infrastructure at all.
Begin by figuring out exactly what’s running on your checkout page. Build an inventory of every script, document why each one is there, and get rid of anything that doesn’t have a clear business reason to be on that page.
PCI DSS v4.0.1 now demands exactly this. Requirements 6.4.3 and 11.6.1, which became mandatory on 31 March 2025, were written to target this particular threat. Under 6.4.3, every script on a payment page must be authorised, justified, and integrity-checked. Requirement 11.6.1 adds tamper detection on top of that, so you’ll get an alert if a script changes without approval. For most online merchants, the good path to closing this gap is to become PCI DSS compliant with the current version of the standard, which now treats payment-page script management as a core obligation.
On top of that, you can use Content Security Policy headers to stop which domains are allowed to serve scripts on your checkout. Go through your tag manager too, and pull out any tags that fire on the payment page without a better reason.
Card skimmers work because nothing looks broken. The checkout functions fine, the customer gets their order, and the only clue is a fraud report that turns up weeks later and gets traced back to your site. By then, your bank may have flagged you for a remediation programme, hiked your processing fees, or done something worse.
These attacks keep getting difficult to detect, too. Modern skimmers obfuscate their code, rotate the servers they exfiltrate data to, and only activate on payment page URLs so they stay completely dormant during routine testing. If you treat checkout security as a one-time box to tick, that’s precisely the kind of opening these attacks are developed to find.
Merchants who actually stay on top of this are the ones who treat every single script on their payment page as a real risk, because outsourcing the payment form to a trusted provider doesn’t mean the whole threat goes with it.
What is client-side skimming (Magecart)?
Client-side skimming, or a Magecart attack, is the act of injecting malicious code into a web page in order to harvest payment details from the client’s browser before reaching the payment processor.
How is it that an SSL/TLS certificate cannot stop card skimmers?
The main purpose of the issuance of SSL/TLS certificates is to ensure that no one can access the information between a user and a web server. With the client-side skimmers working only within the browsing session itself, they take information before it is encrypted.
Can a Web Application Firewall (WAF) stop checkout skimming attacks?
The regular WAF’s job is to examine incoming traffic directed at the website origin servers. As skimmers work within the user’s browser in order to send data to the attacker, it is impossible for the firewall to detect the theft.
What is Subresource Integrity (SRI) and how does it work?
Subresource Integrity is a function of the browser that checks if the fetched script matches the hash provided in your HTML. When the hash does not match, it means that the script was altered by an attacker.
Client-side skimming, or a Magecart attack, is the act of injecting malicious code into a web page in order to harvest payment details from the client’s browser before reaching the payment processor.
The main purpose of the issuance of SSL/TLS certificates is to ensure that no one can access the information between a user and a web server. With the client-side skimmers working only within the browsing session itself, they take information before it is encrypted.
The regular WAF’s job is to examine incoming traffic directed at the website origin servers. As skimmers work within the user’s browser in order to send data to the attacker, it is impossible for the firewall to detect the theft.
Subresource Integrity is a function of the browser that checks if the fetched script matches the hash provided in your HTML. When the hash does not match, it means that the script was altered by an attacker.
