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

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 →