How a web skimmer works
An attacker adds a small piece of JavaScript to a page where customers type card or personal details. As the customer types or submits the form, the script copies the values and sends them to a server the attacker controls. The order still goes through normally, so neither the shop nor the customer notices. The name Magecart comes from early attacks on Magento shops; today the same technique targets any platform. It is also called formjacking.
How skimmers get onto a site
- An outdated platform, plugin or extension with a known vulnerability.
- A stolen or guessed administrator password, often without two-factor authentication.
- A compromised third-party script: a chat widget, analytics tag or library the checkout already loads from someone else's server.
- Code edited directly in the theme or template after a previous break-in that was never fully cleaned.
Warning signs
- A script on the checkout loading from a domain you do not recognise, often one that imitates a real service (for example a misspelled analytics or CDN name).
- Obfuscated code in theme files or in the page: long strings of encoded characters,
evaloratobcalls. - Customers reporting fraud on cards used only in your shop, or your payment provider contacting you.
- New administrator accounts or changed files you did not make.
How to detect it
- Keep an inventory of every script your checkout pages load, and check it regularly against what you expect.
- Get alerted when a new script source appears on a payment page. With Webforta key pages, each checkout page you add is checked with your monitoring and a script from a new server alerts you at once.
- Check payment pages for injected code. A free malware scan looks for obfuscated scripts, hidden iframes and scripts served from raw IP addresses.
- Watch the server side too: file integrity checks (the free Webforta plugin does this for WordPress) catch modified theme and core files.
Outside checks see what a page serves to them. A skimmer that activates only for some countries, devices or signed-in customers can be missed, so combine detection with prevention.
How to prevent it
- Keep the platform, extensions and themes up to date, and remove the ones you do not use.
- Use two-factor authentication on every administrator account.
- Load as few third-party scripts on checkout pages as possible, and add Subresource Integrity (an
integrityattribute) to the ones you keep, so a modified file is refused by the browser. - Set a Content-Security-Policy on checkout pages that allows scripts and form submissions only to the servers you use. The security headers checker shows what your pages send today.
- Where possible, let customers type card details on the payment provider's own hosted page or embedded fields.
The shapes skimmers take
- A new script tag: the simplest form, a
<script src>pointing at a domain the attacker registered, often named to look like a CDN, analytics or payment service. - Code inside a file you already load: the attacker edits your own theme or bundle file, so no new address appears. File integrity checks on the server and hourly checks for injected code are the way to catch this.
- A compromised third party: a widget or library hosted by another company is changed at the source, and every shop that loads it is affected at once. Subresource Integrity stops the browser running the changed file.
- A fake payment form: instead of copying the real form, the script shows its own convincing card form, or a fake "payment failed, try again" step, then sends customers on to the real one.
- Hidden in images or settings: code stored in the database (for example in a CMS setting or a product description) and assembled in the browser, which is why server-side file checks alone are not enough.
A simple monthly routine
- Open each checkout step and compare the scripts it loads with last month's list.
- Review administrator accounts and remove any you do not recognise.
- Apply pending updates to the platform and every extension.
- Run a scan and the free malware scanner on the checkout pages.
Card skimming and PCI DSS
PCI DSS 4.0 asks merchants to keep an inventory of the scripts on payment pages, justify each one, and detect unauthorised changes to payment pages (requirements 6.4.3 and 11.6.1). Monitoring tools can support that work, but compliance is decided by your assessor or self-assessment, not by a tool.