Picture this: your Christmas season went well and your online shop’s sales broke records. You sit back, open a bottle of fizz and look at the figures with satisfaction. Then, in mid-January, the phone rings. First it’s just one angry customer, saying suspicious charges have appeared on their card since they bought from you. Then comes the second call. Then the police or the bank get in touch.
Your website appears to be working perfectly. There are no error messages, nothing has crashed, everything looks fine in the admin area. Yet behind the scenes, an “invisible pickpocket” has been sitting at your checkout for weeks, copying every card number typed in.
This is digital skimming (also known as e-skimming or a Magecart attack), which by 2025 had become one of the most feared enemies of online shops. In this article, we look at how it happens and why traditional antivirus tools are powerless against it.
But I use a secure payment gateway!
This is the first and most important myth we need to dispel. Most online shop owners reasonably think: “I use Stripe / PayPal / Worldpay, so the card details aren’t even with me – they’re on the payment provider’s secure page.”
That’s true. But in 2025, skimmers (data-stealing code) no longer try to steal data from your server. Instead, they plant themselves in your customer’s browser.
When a customer is on the checkout page, their browser loads a huge number of things: your website’s code, fonts, analytics modules, the chat window, marketing pixels. If the attacker manages to place a tiny piece of malicious JavaScript anywhere in this chain, that code can “read” what the customer types on their keyboard – before they even press the “Pay” button and the data is sent, encrypted, to the payment provider.
The “supply chain” attack: when it isn’t you who gets hacked
The big change in 2025 is that hackers have realised a well-protected WooCommerce shop is hard to break into. It is much easier to hack a less well-protected plugin or a third-party service that the shop uses.
For example: do you use a “Wishlist” plugin or a currency converter widget? If that plugin’s developer is hacked and the code is modified in an update, your online shop will download that update completely cleanly and legitimately – and the Trojan horse along with it.
There’s no virus on your server. Your password hasn’t been stolen. And yet, code is running on your checkout page that sends every keystroke to a server in Russia or China.
Technical details: how does JavaScript injection work?
(This part is for developers and anyone interested in IT security)
By 2025, the technical workings of modern skimmers had become extremely sophisticated:
DOM-based monitoring: The malicious JavaScript attaches
event listeners toinputfields (e.g. card number, CVC). As soon as the user presses a key (akeydownorchangeevent), the script records the value.Obfuscation: The code doesn’t look like a virus. It is often hidden under a completely harmless-looking name, such as
google-analytics-tag.jsorjquery-min.js, and its contents are turned into an unreadable jumble of characters that is impossible to interpret with the human eye.Exfiltration: The stolen data isn’t sent by email. The script often sends it to the attacker’s server as a request disguised as a harmless image file (e.g.
favicon.png?id=StolenDataBase64Encoded), so firewalls let it through, thinking it’s just an icon loading.Overlay attacks: If the shop uses an iframe-based payment form (where the payment provider’s form opens in a frame), the skimmer can draw an invisible or fake layer (overlay) over the original field, so the user is actually filling in the hacker’s form, not the provider’s.
Why doesn’t the antivirus notice?
This is the scariest part. Most server-side malware scanners examine files on the disk. But skimming code is often:
Dynamic: It hides in the database (e.g. as part of a setting in the
wp_optionstable), which file scanners can’t see.Loaded from an external source: The code isn’t physically on your server at all; it is loaded into the visitor’s browser from an external URL. Your server is “clean” – it’s the visitor’s browser that is “infected”.
The solution: protection in the browser (CSP) and change monitoring
In 2025, online shop security is unthinkable without a Content Security Policy (CSP). This is a kind of house rule that your server sends to the browser.
Think of it as a security guard at the door with a guest list. The CSP tells the browser: “From this website, data may only be sent to the servers of Google Analytics, the Facebook Pixel and Stripe. If anything else (e.g. an unknown server) tries to connect, BLOCK it immediately!”
With a well-configured CSP, even if the hacker’s code gets into your online shop, it won’t be able to get the stolen data out, because the browser will block the connection.
The other key is file change monitoring. A professional security system alerts you immediately if any JavaScript file in your shop changes – even if only a single line has been added.
4 techniques of the modern skimmer
1
DOM-based monitoring
Event listeners on input fields – copying at the moment of typing.
2
Obfuscation
Code scrambling: an unreadable jumble of characters to scanners.
3
Exfiltration
Data leaves disguised as an image file: favicon.png?id=…
4
Overlay attack
A fake layer over the iframe payment form – you’re typing for the fraudster.
Why doesn’t the antivirus see it?
Dynamic code
It doesn’t live in a file: it hides in the database (e.g. wp_options) – the file scanner walks straight past it.
External source
It loads as an innocently named script: google-analytics-tag.js, jquery-min.js – arriving at runtime.
If you suspect something – immediate steps
- Switch off payments in your online shop immediately
- Don’t start fixing it yourself – the logs are evidence
- Contact a security expert straight away (WPShield: checkout check)
Effective protection: Content Security Policy (CSP) + file change monitoring – WPShield provides both.
Frequently asked questions
If I redirect the customer to the payment provider’s page to pay, am I protected?
You’re in a better position, but you’re not 100% protected. In this case, hackers can “hijack” the customer at the moment they click the button. The customer thinks they’ve landed on the payment provider’s page (because the design is similar), but they’ve actually been taken to a phishing page. They enter their details there, then the script throws an error message and sends them back to the real payment page. The customer just thinks “it didn’t work the first time”, but their details have already been stolen.
Will I ever notice this in the admin area?
No. This type of attack is specifically designed to stay invisible. It doesn’t slow the site down, doesn’t show adverts and doesn’t delete anything. It just watches quietly. It often goes unnoticed for months if there is no active code monitoring (file integrity monitoring).
What should I do if I’m suspicious, or if customers report problems?
Switch off payments immediately (or put the site into maintenance mode)! Don’t try to “fix” it yourself, because the evidence (logs) may be important for the bank or the authorities. Contact an expert straight away who can analyse the malicious code and find the security hole the attackers got in through.
Running an online shop and not sure your checkout is "clean"?
Don’t risk your customers’ trust – ask us for a check today!
