Magecart detection

Magecart is the pattern where an attacker adds a small piece of JavaScript to a checkout page that copies what the customer types and sends it somewhere else. The page keeps working, the order completes, and nothing looks wrong — which is why these go undetected for months. Our sentinel watches for the part that cannot be hidden: the data leaving.

What the sentinel watches

A small script is injected at the top of <head>, before any of your page's own code runs. It wraps the three ways a page can send data out and notes the destination of each:

• fetch() requests that carry a body
• XMLHttpRequest sends
• Form submissions, including ones triggered by script

A request to a host that is neither your own nor on your approved list is reported. The report carries the destination and the page it happened on — never the data itself.

Why it runs first

The sentinel is injected ahead of your own scripts for a reason: it wraps fetch and XMLHttpRequest before anything else gets a reference to them. A skimmer that loads afterwards goes through the wrapped versions whether it wants to or not.

Setting it up

1. Turn on the sentinel

   On the domain's Protection tab, enable Magecart Sentinel. It starts being injected on the next request.

2. Approve the hosts that belong

   Add the third-party hosts your page legitimately talks to — analytics, payment processors, chat widgets — to the allowed list. Your own hostname is always allowed.

3. Watch the Magecart tab

   Alerts arrive as they happen, with a notification. After a day of real traffic the list should be quiet; anything still appearing is either a host you forgot to approve or something worth looking into.

Reading an alert

Each alert names the kind of outbound call and where it went:

Three ways to read one:

• A host you recognise — approve it, and it stops reporting.
• A host you half-recognise — likely a tag added by a marketing tool or a plugin. Worth confirming who added it and why before approving.
• A host you do not recognise at all, on a page with a form — treat it as an incident. Check what script is making the call before anything else.

How it fits with CSP and SRI

The three protections catch a skimmer at different moments, which is why they are worth running together:

A well-built CSP stops most of this before the sentinel ever fires. The sentinel is what catches the case where the script came from somewhere you already allowed — a compromised dependency, or a tag added by someone with legitimate access.