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

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 →