Back to compare

One of these sits between your visitors and your JavaScript

c/side is a proxy: your scripts are routed through their infrastructure so they can be inspected and blocked there. Report URI is a client-side security platform: your policy is enforced by the browser itself, which refuses what it disallows and records what it ran. That difference decides what each one can stop, what each one can see, and what your site now depends on.

Proxy

c/side

Scripts are routed through their infrastructure, inspected server-side, and can be blocked before they reach the browser.

Client-side security platform

Report URI

Script delivery is untouched. The browser refuses what your policy disallows, reports what it ran, and verified copies of that code are archived.

Where Each One Sits

The position is the product.

To stop a script before it executes, something has to stand between the origin serving it and the browser running it. That capability and that dependency are the same architectural fact, and the diagram below is the whole comparison in one picture.

Proxy

Script origin Their proxy Browser

Your third-party JavaScript is delivered through another company's infrastructure. That is what makes inline blocking possible, and it is also a new dependency in the path of your pages loading.

Client-side security platform

Script origin Browser Report URI

Your policy travels with the page, so the browser refuses unauthorised code at the moment it would have executed — and reports what it did. Nothing of ours is ever in the way of a page rendering.

Head to Head

What follows from each architecture

Structural consequences rather than a feature scorecard. Both approaches are legitimate; they optimise for different things.

Consideration	Proxy	Report URI
Script delivery	Carried through their infrastructure	Unchanged — scripts load from wherever they always did
If the vendor is unavailable	Something in the path of your page is unavailable	Your site serves exactly as normal; reports queue up
Blocking	Inline, at the proxy, before the browser sees the code	By the browser itself, under your enforcing policy
Evidence of execution	What the proxy forwarded	What the browser actually ran, reported by the browser
Script payloads	Held, having been fetched by the proxy	Held, and hash-verified against the browser's own fingerprint
Coverage	Scripts routed through the proxy	Every real session, including authenticated pages and checkout
Report types	Script monitoring, with a CSP endpoint alongside	Fourteen, spanning scripts, connectivity, isolation and identity
Deployment	Route your scripts through them	One response header

Worth Correcting

We do read the JavaScript

The standard argument against anything built on browser reporting is that it sees policy violations but never script contents. That is a fair description of a plain CSP endpoint, and not a description of this one.

Script Vault

Fetched, hash-verified, and kept

Browsers report a cryptographic fingerprint of every script they execute. We fetch that file, hash what we receive, and archive it only when the bytes match. The stored copy is therefore provably the code that ran on a real visitor's machine — a stronger artefact than a file fetched by a crawler, which only shows what an origin served that request.

Learn more about Script Vault →

Enforcement Without a Proxy

The browser is already an enforcement point

Blocking does not require a middleman. An enforcing Content Security Policy has the browser refuse unauthorised scripts outright; Integrity Policy requires that scripts carry integrity metadata; Permissions Policy withdraws capabilities entirely. All of it is enforced by the browser, which is closer to the visitor than any proxy can be.

Learn more about Content Security Policy →

Get Started

Try it without routing anything.
Free for 30 days.

One header. No code. Nothing added to your site and nothing in front of it.

Start Free Trial All comparisons →

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

Track Record

Who runs this

Report URI has collected browser security telemetry since 2015. Have I Been Pwned has run on it for years, and our case studies cover several of the most examined client-side incidents in the industry — the British Airways and Ticketmaster Magecart attacks, the European Space Agency, and the cryptojacking compromises at the Information Commissioner's Office and the United States Courts.

The platform is built by people who work on the standards themselves, including Device Bound Session Credentials, passkeys and WebAuthn, with an open-source library published for the former.

Have I Been Pwned → British Airways →