Reporting Endpoint · The foundation

Turn browser reports
into action.
Not logs.

A managed Reporting Endpoint that ingests every report your users' browsers emit, indexes it, and feeds Script Inventory, Alerting, the Builder, the Policy Analyzer, and PCI DSS evidence.

Get a reporting endpoint Read the setup guide

Trusted by security teams at

Engineering teams across SaaS, fintech, healthcare, and e-commerce ship CSPs they can defend.

What we've seen so far

Real reports. Real production traffic.

CSP violations ingested.

Hostnames monitored across our users.

CSP headers analyzed in real time.

The problem

A CSP without reporting is a policy you can't debug, defend, or improve.

Browsers know exactly what your policy blocked. Your servers don't. Every resource you forgot to allow becomes a silent regression you only hear about through support tickets.

01Visibility
You can't observe what your own policy blocks in real browsers.
The browser sees it. The user sees it. Your servers don't. A security control with no telemetry is a guess.
02Debugging
One user's console screenshot isn't a debugging strategy.
A ticket with a console screenshot. A missing widget in one browser on one page. Without a report stream, you spend the afternoon reproducing it instead of fixing it.
03Drift
Vendors push. Browsers update. Your policy stands still.
Tag managers, A/B tools, pixels, CDN versions all change silently. Without reporting, you find out when your policy blocks production traffic.

Primer

What a CSP reporting endpoint actually is.

Browser loads a page with a Content-Security-Policy header. Something violates it. The browser blocks the resource and POSTs a JSON report to a URL you nominated.

That URL is the reporting endpoint. Receiving the JSON is trivial. Turning millions of reports into security signal is where everyone else stops.

References: W3C CSP3 report-to · W3C Reporting API · MDN Reporting-Endpoints

Example violation report · report-uri

{
  "csp-report": {
    "document-uri": "https://example.com/page.html",
    "referrer": "https://google.com",
    "violated-directive": "script-src",
    "effective-directive": "script-src",
    "original-policy": "default-src 'self'; script-src 'self' https://trusted.com; report-uri https://report.centralcsp.com/<myendpoint>",
    "disposition": "report",
    "blocked-uri": "https://untrusted.com/script.js",
    "line-number": 15,
    "column-number": 10,
    "source-file": "https://example.com/page.html",
    "status-code": 0,
    "script-sample": "alert('test')"
  }
}

Where everyone else stops, we start

Not a log viewer. A security platform on top of every browser report.

Other platforms and self-hosted receivers do the same thing: accept the JSON, store it, show it in a table. We read the same stream and turn it into operational visibility into your site's script ecosystem.

A log viewer ends here

What everyone else gives you.

Receives the JSON the browser sends.
Stores it for some retention window.
Shows it in a table with a per-directive filter.
Leaves the rest to your security team's spreadsheets.

A security platform begins here

What we do on top.

Indexed across the whole stream: every directive, origin, hash, and document URL, aggregated like it matters.
Automatic script inventory from report-sha* hashes, with CVE matching.
Alert rules on the live stream: new origins, new scripts, hash drift.
PCI DSS 4.0.1 6.4.3 and 11.6.1 evidence, exportable on demand.
Continuous scanning of your CSP header with concrete recommendations: weak directives, missing fallbacks, BitSight and OWASP gaps.
Builder drafts a tighter CSP from your real production traffic. Every source your app actually loads, not your best guess.
Free crafting tools to author and test before you ship: Chrome Extension, Scanner, Evaluator.

Standards · history & state

Reporting headers: what's what.

report-uri is the original CSP directive. Deprecated in CSP 3 but still honored everywhere.

report-to is the CSP 3 directive. It points at a named endpoint declared via the Reporting-Endpoints response header.

Best practice: set all three. Modern browsers pick report-to, older browsers fall back to report-uri.

References: MDN report-uri · MDN report-to · Our setup guide

Legacy · report-uri (every browser)

Content-Security-Policy:
  …your existing directives…
  report-uri https://report.centralcsp.com/<your-endpoint>;

Modern · Reporting API

Reporting-Endpoints: csp-endpoint="https://report.centralcsp.com/<your-endpoint>"
Content-Security-Policy:
  …your existing directives…
  report-to csp-endpoint;

Setup · what to add and where

Three values. Two headers. Five minutes.

Already have a CSP? Add two lines. No CSP yet? Start in Content-Security-Policy-Report-Only to collect reports without blocking anything. Brand new to CSP? Read Get started with CSP first.

01Step
Grab your endpoint URL
Create a project on CentralCSP and copy the URL. It looks like https://report.centralcsp.com/<your-endpoint>. Live the moment you sign up.
Endpoint URL
```
# Your endpoint after signup:
https://report.centralcsp.com/<your-endpoint>
```
02Step
Declare it with Reporting-Endpoints
Set Reporting-Endpoints on the same responses that carry your CSP. It registers a name (here csp-endpoint) you reference from the policy.
HTTP response header
```
Reporting-Endpoints: csp-endpoint="https://report.centralcsp.com/<your-endpoint>"
```
03Step
Reference it with report-to and report-uri
In your CSP, add report-to csp-endpoint (modern) and report-uri (legacy fallback). Browsers that support both prefer report-to, so you get one report per violation.
HTTP response header
```
Content-Security-Policy:
  …your existing directives…
  report-to csp-endpoint;
  report-uri https://report.centralcsp.com/<your-endpoint>;
```

The full result

Both headers together.

Drop into your reverse proxy, framework, or CDN. The dashboard populates within minutes.

HTTP response headers

Reporting-Endpoints: csp-endpoint="https://report.centralcsp.com/<your-endpoint>"

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-…';
  report-to csp-endpoint;
  report-uri https://report.centralcsp.com/<your-endpoint>;

Lifecycle

Headers in.
Insight out.

One server change. Pays back forever. Every downstream feature reads from the same well.

01
Add the headers
One Reporting-Endpoints header, one report-to in your CSP, report-uri as fallback. No SDK, no extra deploy.
02
Watch reports flow
Real sessions start sending violations within minutes. Directives, origins, and browser context already split out.
03
Filter and drill in
Slice by directive, origin, or browser. Click a row for source file, line, column, original policy, raw JSON. From seconds ago to ninety days.
04
Feed it downstream
Same stream powers Script Inventory, Alerting, the Builder, the Policy Analyzer, and PCI DSS evidence. Wire it once.

How it works

One report in.
Your whole stack reacts.

Reports stream in from every browser, OS, and device your users run. CentralCSP ingests and normalizes them, then turns that single stream into a live dashboard, alerting, a script inventory, a policy builder, and PCI evidence.

On its own, and in context

One endpoint. Every downstream product.

Alone: a dashboard and a debug surface. Wired to the platform: the same stream becomes an inventory, an alert pipeline, a policy generator, and audit evidence.

Reporting alone

What reporting alone gives you.

Managed report-uri + Reporting-Endpoints ingestion.
Real-time dashboard, filtered by directive, browser, origin.
Per-violation drilldown with raw JSON and source-file context.
90-day retention, date-range filtering, browser breakdown.

With the rest of the platform

What unlocks downstream.

Script Inventory reads report-sha* hashes for a per-page script list with CVE signals.
Alerting fires on new origins, new scripts, hash drift. Slack and webhook out.
Builder drafts your next policy from real traffic, OWASP and BitSight checks baked in.
PCI DSS coverage packages evidence for 6.4.3 and 11.6.1.

Frequently asked

Questions teams ask before signing up.

Setup, browser support, data handling. Missing yours? Reach out.

Five minutes to your first report

Stop guessing.
Start collecting reports.

Add the headers, point report-to at CentralCSP, watch real traffic populate the dashboard.

Get a reporting endpoint

Turn browser reportsinto action.Not logs.

Real reports. Real production traffic.

A CSP without reporting is a policy you can't debug, defend, or improve.

You can't observe what your own policy blocks in real browsers.

One user's console screenshot isn't a debugging strategy.

Vendors push. Browsers update. Your policy stands still.

What a CSP reporting endpoint actually is.

Not a log viewer. A security platform on top of every browser report.

What everyone else gives you.

What we do on top.

Reporting headers: what's what.

Three values. Two headers. Five minutes.

Grab your endpoint URL

Declare it with Reporting-Endpoints

Reference it with report-to and report-uri

Both headers together.

Headers in.Insight out.

Add the headers

Watch reports flow

Filter and drill in

Feed it downstream

One report in.Your whole stack reacts.

One endpoint. Every downstream product.

What reporting alone gives you.

What unlocks downstream.

Questions teams ask before signing up.

What is a CSP reporting endpoint, exactly?

How do I wire it up in my CSP?

Do I need report-uri or report-to or both?

How is this different from other platforms or a self-hosted endpoint?

What happens at high traffic volumes?

What data does the endpoint store? Is this GDPR-clean?

How long is data kept and can I export it?

Stop guessing.Start collecting reports.

Turn browser reports
into action.
Not logs.

Headers in.
Insight out.

One report in.
Your whole stack reacts.

Stop guessing.
Start collecting reports.