From the blog

You've read the posts. This is what I built.

Report URI is the platform behind a decade of writing about Content Security Policy, HSTS and Certificate Transparency — and behind Security Headers, which you have probably already used. It watches what actually executes in your visitors' browsers, from one response header.

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

Scott Helme

Scott Helme

Founder of Report URI

Creator of Security Headers

Why This Exists

Writing about CSP is easy. Operating one is not.

Every post about Content Security Policy ends at the same place: deploy it in report-only, look at what comes back, then tighten. That last part is where people stop, because the reports arrive as a firehose of JSON from every browser on the internet and nothing useful happens to them. Report URI started as the missing piece — somewhere for the reports to go that turns them into a policy you can actually ship.

Built From Practice

The tooling came out of doing it

The CSP Wizard, the report filtering, the noise controls — each exists because deploying policies on real sites made the gap obvious. None of it is theoretical, and none of it assumes your site is tidy.

Browser-Native

Nothing of ours runs on your pages

Nothing installed, nothing injected, nothing in front of your application. The browser already reports this; we are the endpoint it reports to. Your site works exactly the same if we are having a bad day.

Same Standards

CSP, HSTS, CT and everything since

The standards covered on the blog are the ones covered here: Content Security Policy, Certificate Transparency, Permissions Policy, COOP and COEP, NEL, DMARC. If it reports from the browser, it lands in one place.

You've Probably Met It Already

Security Headers, the CSP Builder, the analyser

The free tools are all from the same place. They stay free, they always will, and they are the fastest way to see whether any of this is worth your time.

The Free Tools

Scan first if you'd rather

Security Headers grades what you serve. The CSP analyser reads a policy back to you. The CSP Builder writes one. None of them need an account, and all of them exist because the alternative was doing it by hand. If you have used one of them, you have already used part of this.

See all the free tools →
What The Paid Side Adds

Continuous, rather than whenever you remember to check

A scan tells you about the pages a crawler can reach, on the day you ran it. Reports come from every real session — behind logins, in checkout, in whichever region your CDN is having a moment. That is the difference between an audit and monitoring, and it is the whole product.

Learn more about Script Watch →
Get Started

One header on your site. Reports before you finish reading this.

Full access for 30 days. Nothing to install, nothing running on your servers.

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

Not Just Me

Troy Hunt has run Have I Been Pwned on it for years

Troy joined as Strategic Partner in 2017, and Have I Been Pwned — the largest free breach search service there is, at the sort of traffic that finds every weakness in an architecture — has been running on Report URI for far longer than that.

“Report URI has been an integral part of Have I Been Pwned's security posture for many years now. The visibility it gives me into CSP reports in particular has been enormously valuable, I'd never roll out a CSP without it!” — Troy Hunt

Setup

You already know how this goes

Report-only header, endpoint pointed here, wait for real traffic, read what comes back, tighten. The same sequence every post on the blog recommends — the only difference is that the reports land somewhere that groups, filters and de-duplicates them instead of somewhere you have to write yourself.

You don't need a working policy to start. This blocks nothing and tells you everything.

Minimal setup — no existing CSP
Content-Security-Policy-Report-Only: script-src 'self';
  report-uri https://your-subdomain.report-uri.com/r/d/csp/reportOnly

Already running a policy? Add the endpoint to your existing report-uri directive and the data starts arriving from the next page load.

Nothing installed, nothing injected, nothing in the request path

Report-only blocks nothing while you look

Your site is unaffected if we are unavailable

Covers authenticated pages no scanner reaches

Cancel from the billing page, no conversation required