Client-Side Security for Security Engineers

The detection surface your stack was never pointed at

Your detection coverage is good where your tools look. The WAF sees requests to origin. The SIEM correlates server-side logs. EDR watches the endpoint.

None of them see what executes in the browser after the page loads. Magecart exfiltration goes straight from the user's browser to attacker infrastructure — it never crosses a boundary your tooling inspects. The server logs look normal. The alert never fires, because nothing is watching the layer where it happened.

What the browser reports when you're listening

The browser will tell you what's happening in it — through native reporting, not injected code.

CSP Reporting

Every policy violation from real browsers: attempted injections, unauthorised script loads, blocked sources. Detection events your SIEM never receives today. See how CSP reporting works →

Script Watch

Change detection on every JavaScript dependency. A script that changes, moves, or starts behaving differently in an authenticated session is a reliable indicator of a client-side compromise in progress. See how Script Watch monitors your JavaScript →

Data Watch

Data leaving the page to destinations it shouldn't reach. The exfiltration signal, at the point it happens. See how Data Watch tracks your data →

These are feeds you can route, review, and build response around.

How long an injected script runs before anyone notices

The metric that matters is how long hostile code executes before you catch it.

The Instructure Canvas breach is the case study: a stored-XSS payload ran in an authenticated session and exposed 275 million student records. With a strict CSP, that injection generated a violation report on every page load. As Report URI's founder Scott Helme documented, the signal existed for four days — the reports just weren't going anywhere anyone watched.

Detection drops from days to the first page load — if the reports land where your team already looks.

Signal, not another noisy dashboard

You've onboarded feeds that turned into noise nobody triaged. The concern is fair.

Policy-based enforcement is what keeps this clean: you define what's allowed, so a violation is a real deviation from policy — not ambient event volume. A useful alert means something actually broke a rule you set.

This is designed to land in your workflow as signal you can act on, not a fourth dashboard to babysit.

One header, no agent, no proxy

Report URI works through the browser's Reporting API. Add your reporting endpoint to your Content-Security-Policy header. That's the deployment.

Content-Security-Policy: default-src 'self';
  report-uri https://your-subdomain.report-uri.com/r/d/csp/enforce

Browser-native. No agent, no proxy in the path, no code changes — and nothing new to fail an availability review. The site is unaffected if Report URI is unavailable.

What it pairs with, what it doesn't replace

It doesn't replace what you run. It feeds the layer they can't see — telling you when a control has already been bypassed, before the session or the data is gone. The full guide to client-side security →

Trusted by teams monitoring the browser layer

Have I Been Pwned runs Report URI to monitor for malicious JavaScript and unauthorised data exfiltration — treating the browser as a detection surface, not a display layer.

Report URI was founded by Scott Helme, who finds and publicly discloses client-side attacks from real CSP report data — the Canvas breach dwell-time analysis and live Magecart campaigns among them. Read the case studies →