Compare

No two of these protect the same thing

Proxies, browser agents, remote scanners, sandboxes, CDN add-ons and client-side security platforms are not variations on one product. They sit in different places, and where a tool sits decides what it can see and what it can stop. That, rather than a feature list, is what should drive the choice.

Read the comparisons →
8
Architectures
8
Comparisons
0
Scripts we add
10
Criteria
The Real Distinction

Everything else can take your site down.

Feature lists in this category converge, because everybody eventually ships an alert, a dashboard and a compliance report. What does not converge is where each tool sits between your servers and your visitor's screen. A server-side component runs inside your application, a proxy carries your scripts, an agent and a sandbox load on your page. Every one of those is something of theirs that can fail while your customers are mid-session, and when it does it is your incident. We are in none of those positions.

Server side
Code protection
If it fails
Your site can go down.
In the delivery path
Proxy CDN add-on
If it fails
Your site can go down.
On the page
JavaScript agent Sandbox
If it fails
Your site can go down.
In the browser
Report URI
If we fail
Your site is unaffected.
Not on this line

Remote scanners are not on this line at all. They visit from outside on a schedule, so they see what your site serves a robot, not what it serves your customers.

Comparisons

By architecture

Each column is an approach rather than a product, because where a tool sits decides what it can see and what it can stop. We do not quote anyone's pricing or link out to a competitor, because both change without notice and a comparison that leans on them is wrong the day they do.

Criteria Why it matters Report URI Proxy Remote scanner JavaScript agent Sandbox CDN add-on Reporting endpoint
Sees your real visitors Card skimming targets the pages behind a login, and payment steps are rarely reachable from outside.
Stops unauthorised code executing Detection tells you what already ran. Refusing the code is what prevents the loss.
Evidence of what the browser ran After an incident, what a robot was served is not what your customer was served.
Keeps a verified copy of the script Recording that something changed is not the same as holding the file that changed.
Nothing added to your site Anything shipped to your pages needs reviewing before every release, and it costs your visitors time.
Cannot take your site down When something of theirs fails while your customers are mid-session, it is your incident.
Works across every host and CDN Estates are rarely on one provider, and the tooling should not decide who is allowed to serve what.
Covers more than scripts Certificates, email authentication, transport security and cross-origin isolation all break silently.
Cost does not follow your traffic A good week should not arrive with an invoice attached. Anything a visitor's pageview has to pass through is metered by how many of them there are.
Effort to get started A long rollout delays the protection and spends engineering time before you are covered at all. Low High Low Medium High Low Low
Yes Partial No

How each approach works

What the architecture does, where it runs out of road, and the page that explains it in full.

Approach How it works Where it runs out of road Comparison
Report URI Client-side security platform Your security policy is built into your web pages. The browser blocks any code that is not authorised, then sends us a summary of what ran and what was blocked. We keep an exact copy of the code that ran. Our telemetry comes from real visitors using real browsers, so you need traffic to your website to provide us with data. The browser only blocks what your security policy disallows, so you need to provide us with reliable information about what code you expect to appear on your site. The platform →
Proxy c/side Your third-party scripts are re-pointed at the vendor, who fetches each one, inspects it server-side and serves it on. Because everything passes through them, unwanted code can be stripped before a browser ever sees it. The delivery of your pages now depends on a company that is not you, and only what you route through it is covered. A script a partner adds later loads the old way, unseen. Full comparison →
Remote scanner Reflectiz A crawler visits your site on a schedule from the outside, records the scripts it finds and the requests they make, and reports what changed between runs. Nothing is added to your site to make it work. It sees what your site serves a robot. Logged-in pages and checkout steps are reached only by simulating a customer, and code that misbehaves for real visitors can behave itself for a scan. Full comparison →
JavaScript agent Feroot A script belonging to the vendor loads on your pages and watches the others from inside, instrumenting browser APIs, recording what they do and raising alerts on what it sees. Anything executing before the agent loads is a blind spot, and code running alongside it sits at the same level and can interfere with it. It is also one more third-party script on the pages you are trying to keep clean. Full comparison →
Sandbox Source Defense Third-party scripts are wrapped in a layer that constrains what each vendor may do, which fields it may read and which endpoints it may reach, and that layer enforces the permissions as the page runs. A permission set has to be written and revisited for every vendor, and anything not routed through the wrapper is neither constrained nor observed. Full comparison →
CDN add-on Cloudflare Page Shield Client-side security is switched on inside a CDN you already run, using the traffic that platform is already serving to inventory scripts and manage a policy. Coverage stops at the properties that platform serves, so a mixed estate has to be consolidated first, and moving provider takes the tooling and its history with it. Full comparison →
Reporting endpoint URIports Browsers already send a report whenever a policy is violated. A reporting endpoint collects, stores and presents them, so you can see what your policy caught. Reports carry metadata rather than code, so a script that changed shows up as a URL that appeared. Getting from those reports to an enforcing policy, and holding evidence of what actually ran, is left to you. Full comparison →
Code protection Jscrambler Your own JavaScript is obfuscated and hardened as part of your build, making it difficult to read, tamper with or run anywhere other than your pages. It applies to code you can rebuild. The third-party scripts that carry most of the client-side risk are not yours to compile, so they stay out of reach. Full comparison →
Your own endpoint Build it yourself You point your policy at a destination you host, and write the reports browsers send into your own storage to query however you like. It is a public, unauthenticated endpoint anyone can flood, most of what arrives is browser-extension noise, and each further report type is another parser to write. The cost never stops. Full comparison →
Where We Sit

The browser is the enforcement point. We are how you use it.

Report URI is a client-side security platform. Every modern browser can already refuse unauthorised scripts, withdraw capabilities your site never uses, and reject code that arrives without integrity metadata — it just needs to be told what to allow. We are where that policy gets decided, deployed and kept honest, and where the browser reports back what it enforced.

That makes the browser your enforcement point rather than a box in front of it. Unauthorised code is refused at the moment it would have executed, on the visitor's own machine, below anything a script on the page could reach. Nothing of ours runs on your site, so there is nothing to review before a release, nothing to slow a page down, and nothing that stops working if we have a bad day.

The record comes from the same place. Because it is generated by real sessions it covers the pages an outside visit never reaches — authenticated areas, the checkout flow, region-specific content, whichever variant a customer was bucketed into. And because browsers report a cryptographic fingerprint of every script they execute, we fetch that file, re-hash it, and archive it only when the bytes match, so the copy we hold is provably the code that ran. Fourteen report types arrive through the same endpoint.

Script Vault → The platform →
Get Started

Try it on your own site.
Free for 30 days.

One header. No code. Reports start arriving from your first visitor.

Start Free Trial Talk to our team →

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

Evaluating

Six questions worth asking any vendor here

These separate the architectures faster than a feature matrix does, and they apply to us as much as to anyone else — so our own answer is on each one.

01

Does this see my authenticated pages?

Anything driven by an external visit sees only what is publicly reachable, and payment flows usually are not. Card skimming targets the pages behind a login.

Our answerYes. Reports come from your customers' own sessions, wherever they are.
02

What is added to my site, and what happens if it fails?

A proxy sits in the path of your pages loading. An agent is a script running on them. Either one can take your site down, and it will be your incident, not theirs.

Our answerNothing is added, so there is nothing of ours that can fail. If we go down, your site serves and enforces exactly as before.
03

Can you show me the actual script, months later?

After an incident the artefact is what matters. Most tools describe that something changed rather than keeping the file that changed.

Our answerYes. Script Vault archives hash-verified copies of the code browsers really executed.
04

Does this cover anything beyond scripts?

Certificates, email authentication, transport security, cross-origin isolation and network failures all break in ways that matter, and they break silently.

Our answerFourteen report types, all arriving through the same endpoint you already configured.
05

Is the pricing published, and what does the meter count?

A quote-only vendor puts a procurement cycle between you and knowing whether the product suits you at all. The meter matters just as much: billed by pageview, the better your year goes the more you owe for it.

Our answerPublished, every tier, on the pricing page. No sales call to find out. We count the reports your policy generates rather than the visitors you get, and there is no overage billing, so a sudden good month cannot arrive as a surprise invoice.
06

How quickly can I prove it works?

Anything needing a deployment, an agent rollout or a sales call is slower to evaluate than a header you can set this afternoon.

Our answerSet one header and reports arrive from your first visitor. There is nothing to deploy.