Report URI vs Source Defense

Where Each One Sits

A layer around the script, or a rule the browser enforces.

To constrain a script from outside it, something has to stand between the script and the page: a wrapper, a virtualised environment, a permission broker. That something must be loaded, kept current with every vendor's behaviour, and trusted with the page it is protecting. The browser is already in that position, and it got there first.

Sandbox

Your page Wrapper layer Third-party script

A layer to deploy and maintain, plus a permission policy per vendor that has to be kept accurate as those vendors change what they do.

Client-side security platform

Your page Browser enforces policy Report URI

The constraints are response headers the browser applies itself, and the record of what happened comes from the same place.

Head to Head

What follows from each architecture

Fine-grained control over an individual vendor against native enforcement and a complete record of what ran.

Consideration	Sandbox	Report URI
Enforcement point	A layer you add to the page	The browser, from response headers you already control
Added to your pages	Yes — the sandboxing layer itself	Nothing
Ongoing maintenance	A permission policy per vendor, revisited as vendors change	A policy per site, built from what browsers actually reported
Scripts not routed through it	Unconstrained and unobserved	Still reported — the browser sees everything on the page
Granularity	Fine-grained per-vendor permissions over page APIs	Origin, capability and integrity constraints, browser-enforced
Record of what ran	What the layer permitted or refused	What the browser executed, with verified copies of the code
Report types	Script behaviour and policy decisions	Fourteen, spanning scripts, connectivity, isolation and identity
Deployment	Add the layer and configure per vendor	One response header

Why It Matters Here

The primitives shipped

Most of what a sandbox is asked to prevent now has a native counterpart. These are standards, implemented by every major browser, enforced below anything a script can reach.

Native Constraints

Withdraw the capability, not just the permission to use it

Permissions Policy removes access to the camera, microphone, geolocation and payment request from the page entirely, so no script on it can ask. Content Security Policy decides which origins may be contacted at all, which is what stops exfiltration to somewhere new. Integrity Policy requires that scripts carry integrity metadata before they are allowed to run. None of it can be talked around by code on the page, because none of it is enforced by code on the page.

Learn more about Permissions Policy →

Script Vault

Constraining a script is not the same as knowing what it was

A permission model tells you what a script was allowed to attempt. It does not leave you a copy of the code. Browsers report a cryptographic fingerprint of every script they execute; we fetch that file, re-hash what we receive, and archive it only when the bytes match — so the stored copy is provably the code that ran on a real visitor's machine. That is the artefact an incident review and an assessor both ask for.

Learn more about Script Vault →

Get Started

Use the sandbox you already have.
Free for 30 days.

One header. No code. No per-vendor policy to keep up to date.

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 requirements 6.4.3 and 11.6.1 ask you to authorise the scripts on payment pages, justify why each is necessary, assure their integrity, and detect unauthorised change. A record of what browsers really executed, with the files themselves attached, is evidence in the form an assessor can check — not a configuration screen describing what would have been permitted.

PCI DSS 4.0.1 → Evidence pack →

Keep Comparing