Back to compare

A scanner sees your site. We see your sessions.

Neither approach puts code on your pages, which is why they are often shortlisted together. They differ completely in whose experience they describe — an automated visitor's, or your customers' — and in whether they can stop anything at all.

Remote scanner

Reflectiz

Visits your pages from outside on a schedule and reports on what it was served.

Client-side security platform

Report URI

Your policy is enforced by the browsers of the people actually using your site, which also report what they blocked and what they ran.

Where Each One Sits

One is a visitor. The other is every visitor.

A scanner is elegant precisely because it stands outside: nothing to deploy, point it at a domain and go. The constraint comes from the same place. It is served what your site gives an automated request, from one network, without a session, on the pages it can reach unaided.

Remote scanner

Their scanner Your public pages

An automated visit, on a schedule. Your real visitors and their sessions are somewhere else entirely, and so is most of your checkout.

Client-side security platform

Real visitor Browser Report URI

Wherever your customers go, the policy goes with them. Authenticated pages and payment steps are protected and reported because the people on them are logged in.

Head to Head

What follows from each architecture

Both avoid adding anything to your pages. Everything below follows from the vantage point rather than from a feature decision.

Consideration	Remote scanner	Report URI
Data source	An automated visit to your site	Telemetry from your real user sessions
Can it stop anything?	No. A scan reports what it found, after it found it	Yes. An enforcing policy has the browser refuse unauthorised code outright
Authenticated pages	Reachable only by simulating a login	Covered, because your customers are already logged in
Checkout and payment steps	Require the scanner to reproduce multi-step state	Reported as customers move through them
Timing	Whatever was true when the scan ran	Continuous, as the site is used
Personalised content	One variant, one region, one device profile	Whatever your third parties served each real visitor
Script payloads	Fetched by the scanner	Fetched and hash-verified against the browser's own fingerprint
Report types	Page composition and script inventory	Fourteen, spanning scripts, connectivity, isolation and identity
Deployment	Point at a domain	One response header

Why It Matters Here

The pages that get attacked are the gated ones

Card skimming targets payment flows. Those are behind authentication and several steps of state — the hardest place for an outside visitor to reach, and the easiest for real reporting to cover.

Verified Artefacts

The file that ran, not the file we were served

Because the fingerprint comes from a real execution, an archived copy can be proved to match it. That is a different artefact from a file downloaded during a scan, which shows only what an origin chose to serve one automated request from one location.

Learn more about Script Vault →

Get Started

See what your visitors see.
Free for 30 days.

One header. No code. Reports start arriving from your first real session.

Start Free Trial All comparisons →

30-day free trial · One header · No code · Cancel anytime

Compliance

What an assessor is actually asking for

PCI DSS 4.0.1 asks you to know which scripts run on payment pages, to assure their integrity, and to detect unauthorised change to them. Payment pages are exactly the pages that sit behind state, and the strongest evidence is a record of what browsers really executed there, backed by the files themselves.

PCI DSS Compliance → Evidence pack →