Home » Articles » Magecart, E-Skimming and Script Monitoring

Magecart, E-Skimming and Script Monitoring

What this means

Checkout skimming often hides in browser scripts. What Magecart and e-skimming look like, and why watching scripts matters.

Desk with monitors showing code and a cart page

Note: This site may show light ads and occasional affiliate links. How that works.

Magecart and e-skimming attacks still hit checkout pages because they run in the customer’s browser — where ordinary firewalls and antivirus often cannot see them. Script monitoring helps you notice what is loading on the page, and decide which scripts are allowed, blocked, or need a clear business reason.

What is Magecart and e-skimming?

Magecart is a loose label for criminal groups that inject malicious JavaScript into websites — especially online shops — to steal payment card data directly from customers’ browsers. This technique, e-skimming, bypasses traditional server-side security and often stays hidden for months.

In plain terms: someone adds hidden code to your checkout page. When a customer types their card number, that code copies it and sends it to the attacker — while the real payment still goes through. Your customer gets their order. You may not notice anything wrong until chargebacks pile up.

  • Targets: payment pages, shopping carts, checkout forms
  • Impact: PCI violations, reputational damage, financial loss, customer churn

Why script monitoring helps

Firewalls and endpoint protection are built for server and device traffic. They are largely blind to client-side threats — code that runs in the visitor’s browser. Script monitoring fills that gap by analysing what JavaScript is doing on your page in real time.

Allow, block, or question

By watching scripts for unusual behaviour, you can decide what to allow and what to stop:

  • Allow: scripts that match known safe patterns, come from trusted sources, and belong to processes you actually use on your site
  • Block: scripts that access payment fields without permission, send data to unknown servers, or create or change checkout elements — like a rogue card form layered over yours

That gives you:

  • Visibility into third-party and fourth-party scripts and what they do
  • Faster detection — stopping attacks before card data leaves the browser
  • Smaller blast radius when something does go wrong
  • Stronger PCI and GDPR compliance — by preventing unauthorised data collection before it starts

Stop! Pause! Before you add a new widget, chat tool, or analytics script to checkout: Is it urgent? Do you know who supplies it? Does it really need to run on the payment page? If not sure — keep it off checkout until you have checked.

Related: Securing the checkout · PCI DSS SAQ guide · Spot a fake card form.

A self-check

Open your checkout page in a browser. Can you list every script that loads there — analytics, chat, payment helper, theme code? If you cannot, that is the gap. Ask whoever maintains your site for a script inventory, or run a script-monitoring check. You do not need to understand the code — you need to know what is allowed.