Report URI vs a proxy

One of these sits between your visitors and your JavaScript

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. A proxy takes the other position entirely: your scripts are re-pointed at the vendor, fetched and inspected on their infrastructure, and served on from there. That difference decides what each one can stop, what each one can see, and what your site now depends on.

By Scott Helme — CEO and Founder · 12 August 2026

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.

vs
Proxy
Script proxy

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

How To Read This

Written against the category, not a product.

This page describes the proxy approach rather than any one vendor's implementation of it. Products change without notice, and a comparison that quotes a particular feature set is out of date the day it does. Architecture is the durable part, and it is also the part that decides what a tool is able to see and stop. Check the current state of anything you are evaluating for yourself.

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.

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.

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.

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 Report URI Proxy
Script delivery Unchanged — scripts load from wherever they always did Carried through their infrastructure
If the vendor is unavailable Your site serves exactly as normal; reports queue up Something in the path of your page is unavailable
Blocking By the browser itself, under your enforcing policy Inline, at the proxy, before the browser sees the code
Evidence of execution What the browser actually ran, reported by the browser What the proxy forwarded
Script payloads Held, and hash-verified against the browser's own fingerprint Held, having been fetched by the proxy
Coverage Every real session, including authenticated pages and checkout Scripts routed through the proxy
Scripts added later Reported the first time a browser loads one, wherever it came from Covered once someone remembers to re-point it
Deployment One response header Route your scripts through them
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 proxy or a crawler, which shows what an origin served that particular 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

FAQ

Frequently asked questions

A plain endpoint receives violation reports and never sees a line of code, which is a fair description of most of them and not of this one. Browsers report a cryptographic fingerprint of every script they execute; Script Vault fetches that file, re-hashes it, and archives the copy only when the bytes match.

Anything that fetches a script itself is a known client that can be served something other than what your visitors get, so clean code for the fetcher and a skimmer for everyone else defeats it. A hash reported by the browser that ran the code cannot be cloaked that way, because it describes what actually executed on a real visitor's machine.

Blocking is usually presented as something only a middleman can do, when the browser is already an enforcement point and sits closer to the visitor than any proxy. An enforcing Content Security Policy refuses unauthorised scripts outright, Integrity Policy requires that scripts carry integrity metadata, and Permissions Policy withdraws capabilities entirely.

Anything in the delivery path for your scripts is something that can fail in front of your pages, which is the cost of being able to intercept them. Report URI is not in that path: if we are unavailable your site serves and enforces exactly as normal, and reports queue until we are back.

A proxy covers what has been re-pointed at it, so a tag a marketing team or a partner adds later loads the old way until someone remembers to route it too, and nothing announces the gap. Browsers report every script they load regardless of where it came from, so a new one shows up the first time a real visitor meets it.

Both requirements ask you to inventory the scripts on your payment pages, justify them, and detect when they change. Script Watch maintains that inventory from what browsers really loaded, Script Vault keeps the verified file behind each entry, and both cover authenticated checkout pages rather than only what an external scan can reach.
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 →
Keep Comparing

Other tools in this category

Remote scanner
Report URI vs Reflectiz
JavaScript agent
Report URI vs Feroot
JavaScript agent
Report URI vs c/side
Sandbox
Report URI vs Source Defense
CDN add-on
Report URI vs Cloudflare Page Shield
Code protection
Report URI vs Jscrambler
Reporting endpoint
Report URI vs URIports
Every option
CSP reporting alternatives compared