Back to compare

Watching JavaScript with more JavaScript

An agent is a script you add to your pages so it can observe the other scripts. It sees runtime behaviour in detail, and it is also code you are now shipping to every visitor. Browsers already enforce and report much of this natively, without anything being added.

JavaScript agent

Feroot

A script on your pages observes what other scripts do while they run.

Client-side security platform

Report URI

The browser itself enforces your policy and reports what happened. Nothing of ours executes on the page.

Where Each One Sits

Inside the page, or outside it entirely.

An agent has to load, and it has to load early enough to see what it is meant to watch. That places it in the same execution environment as the code it is monitoring, subject to the same conditions — a slow network, a constrained device, a crash, or a script that arrived before it did.

JavaScript agent

Your page Their script loads Observes other scripts

Another dependency on the page, shipped to every visitor, sharing the fate of the environment it runs in.

Client-side security platform

Your page Browser enforces and reports Report URI

Enforcement and reporting are both part of the browser. There is nothing to load, nothing to fail, and nothing extra for your visitors to download.

Head to Head

What follows from each architecture

The trade is depth of runtime observation against not being on the page at all.

Consideration	Report URI	JavaScript agent
Added to your pages	Nothing. One response header on the server side	Yes — a script that ships to every visitor
Stopping unauthorised code	The browser refuses it before it executes, below anything on the page	Detects and alerts; anything it blocks, it blocks from inside the page
Change management	A header. No code review, no release coupling	A third-party script in your page requires review and re-review
If it fails to load	Reporting is the browser's job and does not depend on a download	Monitoring silently stops for that session
Scripts that load first	Policy applies from the first request the page makes	Anything executing before the agent is a gap
Runtime behaviour detail	Reports what the browser enforced, blocked and executed	Can instrument APIs and observe behaviour closely
Script payloads	Fetched and hash-verified against the browser's own fingerprint	Available to the agent at runtime
Report types	Fourteen, spanning scripts, connectivity, isolation and identity	Script and page behaviour
Performance cost to visitors	None — reports are sent by the browser out of band	An extra script to fetch, parse and execute

Why It Matters Here

The reason people care about third-party scripts is the reason to add fewer

A client-side security tool that ships as client-side code is asking for the trust it exists to question. That is not disqualifying, but it is worth naming.

Nothing to Trust

Your site works identically if we are unreachable

There is no script of ours to fetch, so there is nothing to slow a page down, nothing to review before a release, and nothing that stops working if our infrastructure has a bad day. The browser generates the reports either way and delivers them when it can.

Learn more about CSP Reporting →

Get Started

Add nothing to your pages.
Free for 30 days.

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

Start Free Trial All comparisons →

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

Enforcement

Prevention without adding code

Detection is only half of it. An enforcing Content Security Policy has the browser refuse unauthorised scripts before they run, Integrity Policy requires that scripts carry integrity metadata, and Permissions Policy withdraws capabilities your site never uses. All of it is enforced by the browser rather than by a script competing with the code it is meant to police.

Content Security Policy → Integrity Policy →