To detect Magecart in real time, watch scripts as they execute in real shopper sessions and alert the moment one hooks a form field, attaches to the submit button, or opens an outbound destination that was not in the page's baseline. A periodic outside-in scan only tells you what the page returned to a scanner, at a scan location, during a scan window. Modern skimmers are built to avoid exactly that.
The timing gap is the whole problem. A scanner runs every few hours or once a day from a fixed crawler. A skimmer runs in the one session it cares about: a real card holder, in a targeted region, on a targeted device, at checkout. cside closes that gap by observing the same sessions the attacker targets and capturing what each script does at runtime, so a malicious change surfaces while exposure is live, not after a card network forensics report lands.
Why scanners miss conditional skimmers
Magecart payloads increasingly carry guard logic. They decide whether to activate before they steal anything, which means a clean fetch proves nothing.
Common evasion conditions that defeat outside-in scanning:
- Geo-targeting: the payload activates only for IPs in specific countries and serves benign code elsewhere. A scanner crawling from a datacenter region outside the target never trips it.
- Device and UA gating: the skimmer runs only on real mobile or desktop browser profiles and suppresses itself for headless or crawler signatures.
- Time-windowing: activation is limited to certain hours, so a scan that runs at the wrong time sees nothing.
- Session-state gating: the code waits for a populated cart or a checkout route before it arms, which a synthetic scan that loads one URL never reaches.
- Anti-automation checks: the payload inspects for
navigator.webdriver, missing input timing, or absent pointer events and stays dormant when it detects an automated session.
Each condition is a filter that excludes scanners by design. The attacker does not need to defeat your monitoring tool's signature; they only need to recognize that the visitor is not a paying customer in the target segment. That is far easier, and a static snapshot of the file cannot capture a decision the code makes at execution time.
What runtime monitoring sees that a scan never will
Outside-in scanning compares file contents or hashes. Runtime monitoring observes behavior in a live browser, which is a different and larger surface.
| Signal | Periodic outside-in scan | Runtime browser monitoring |
|---|---|---|
| Conditional payload that hides from crawlers | Sees benign version | Sees the version served to the real targeted session |
| DOM / form-field reads on card and login inputs | Not observed | Observed as the script accesses the field |
| Event hooks on submit, keydown, or change | Not observed | Captured when the listener attaches |
| New outbound exfil endpoint at pay-click | Missed unless captured mid-request | Flagged against the page's destination baseline |
| Compromise of an already-allowed vendor origin | Hash/origin still look authorized | Behavior change flags it regardless of origin |
| Obfuscated payload assembled at runtime | Static file looks inert | Visible once it executes and acts |
The behaviors that matter in a digital skimmer are not in the file at rest. They happen when the script runs: it reaches into the DOM, reads value off the card-number input, registers a handler on the form's submit event, then assembles a payload and ships it with fetch, XMLHttpRequest, or navigator.sendBeacon to a look-alike domain at the instant the user clicks pay. Watching execution is the only vantage point that sees that sequence.
The hardest case for hash-based tooling is the supply-chain compromise. A trusted vendor script gets a new, legitimate-looking version from an authorized CDN origin. The hash is new but valid; the origin is on your allowlist. Nothing about the file or its source looks wrong. What looks wrong is the behavior: a script that previously rendered a widget now reads a payment field and posts to a destination it never contacted before. Runtime monitoring baselines what each script does, so a behavioral change trips even when the origin and signature stay inside policy.
An operating plan for real-time detection
The objective is to shorten the interval between malicious change and containment, and to keep evidence that survives a forensic review.
- Monitor production from real shopper sessions, across product, cart, and checkout, not only the payment step, and not from a synthetic crawler.
- Baseline every script's behavior: which DOM nodes it reads, which form fields it touches, which destinations it contacts. Deviation from that baseline is your primary signal.
- Alert on new exfil destinations the moment a script contacts a domain absent from the page's established destination set.
- Alert on new form hooks: a listener attaching to a payment or credential field, or to the submit button, on a script that never did so before.
- Capture the readable payload and per-session timestamps so you can reconstruct what ran, in which sessions, and what data was in scope.
- Route high-severity behavioral alerts straight to incident response with the script identity, the affected pages, and the destination already attached.
Steps 2 through 4 are what convert raw runtime visibility into something an analyst can act on in minutes instead of reverse-engineering obfuscated JavaScript after the fact.
How cside fits
cside instruments real shopper sessions and watches third-party and first-party scripts as they execute. It captures the runtime behavior a scanner cannot reach: form-field access, event-listener hooks on payment and login inputs, and outbound requests to destinations outside the page's baseline. Because detection runs in the same sessions the attacker targets, a conditional skimmer that hides from crawlers still surfaces the moment it acts on a real visitor.
When a script's behavior deviates, cside flags what changed, where it ran, which fields it touched, and where data went, with per-session timestamps and the readable payload preserved for investigation. That gives the owner of the outcome the context to contain exposure while it is still live, and an evidence trail for the questions that follow. The same browser-layer telemetry feeds device and real-IP capture, AI-agent and automation detection, and proxy/VPN behavioral signals through the cside platform.
