The Accountability Problem
The one question about your program you can't fully answer
Someone asks whether the organisation is covered. For most of your program, you have an answer. You know what you deploy, you know what your controls are watching, and you can show it.
Client-side is where the answer gets thin. You control every line of code you write. You don't control what runs alongside it once a third-party script loads in the browser.
Your WAF, SIEM, and IAM aren't failing. They're watching the server, the network, and the identity layer. None of them see what executes in the browser.
That's not a tooling gap you can tune your way out of — it's a layer your program was never pointed at.
The Moving Target
Why the code you approved doesn't stay approved
The scripts you approved don't stay the way you approved them. A tag manager loads what it's told to load, whenever it's told, and never asks you again. A dependency you allow-listed years ago can change owners without a single line of your code changing.
A good example comes from Report URI's founder, Scott Helme, a security researcher who regularly finds and discloses this class of attack. Digging through CSP report data, he surfaced netdna-ssl.com — the asset domain behind a long-dead CDN that thousands of sites still reference in their pages. The domain was re-registered, and whoever holds it now controls DNS across the old namespace. Today those requests fail a TLS handshake rather than execute. The day a certificate gets issued, it flips from “broken asset” to arbitrary JavaScript running in thousands of pages.
The trust was pinned to a domain, not the code — and the domain moved. The same pattern took down Polyfill.io: one trusted domain changed hands, and roughly 100,000 sites came along with it.
Your program feels complete because the deployed surface is covered. The executing surface is the part nobody's watching.
Real Exposure
What actually lands on your risk register
This isn't theoretical. Three attack patterns live in this gap, and none of them touch your servers.
Card skimming (Magecart)
The skimmer runs in the customer's browser and exfiltrates card data directly. Your server-side monitoring sees a normal transaction. Nothing looks wrong until the disclosure. How Magecart attacks are detected →
Session hijacking after login
After all the investment in passwords, MFA, and passkeys, the thing standing between an attacker and a live authenticated session is still a cookie. Attackers follow the value, and the value moved to the session — which passkeys don't protect. What passkeys don't protect against →
Script tampering in a privileged session
The Instructure Canvas breach turned a single support-ticket XSS into 275 million exposed student records. The injected script sat in an authenticated session, quietly reporting itself for four days before anyone caught it.
Each of these is breach liability and disclosure exposure — the kind of event that turns into a board conversation.
The Coverage Standard
What a defensible answer requires
Closing the gap comes down to three capabilities.
Visibility
You can say what's actually executing on your pages right now — not what you deployed six months ago.
Control
You decide what's allowed to run, and that decision is enforced at the point of execution.
Proof
You can produce evidence of both, on demand, for a board member or an auditor.
Together, that's a credible answer to “are we covered?” — not another dashboard for someone to ignore.
No New Risk
What this doesn't add to your program
Report URI is browser-native. It's built on Content Security Policy and the browser's own reporting, so nothing gets injected into your pages. It can't become the next thing that breaks or gets compromised.
No agent. No proxy. No new dependency in the request path. Your site runs normally even if Report URI is unavailable.
It doesn't replace your existing controls. It's the layer that tells you when they've been bypassed. That distinction matters, because some tools sold to close the client-side gap do it by running their own code on your pages — introducing the exact risk you're trying to manage. The full guide to client-side security →
In Practice
Trusted by teams who can't afford a blind spot
Security-conscious teams that can't afford a client-side blind spot run Report URI to answer the coverage question. Have I Been Pwned monitors for malicious JavaScript and unauthorised data exfiltration. Payment providers Paddle and REPAY use it toward their PCI DSS 4.0 obligations. The common thread: knowing what executes, controlling what's allowed, and being able to show it.
The cost of the gap is on the same page. British Airways, Ticketmaster, and the European Space Agency were all hit by Magecart — a card-skimming attack that ran in the browser and never touched their servers. British Airways was fined £20,000,000 because an attacker edited a single file loading on their site. The code wasn't theirs. The penalty was.
Report URI was founded by Scott Helme, who finds and publicly discloses attacks like these from real CSP report data. Read the case studies →
Close the client-side gap in your security program.
One header. No agent, no infrastructure changes.
