report-uri

report-uri names one or more URLs that the browser posts a violation report to. It is the directive that makes CSP observable rather than merely restrictive, and it works identically on Content-Security-Policy and Content-Security-Policy-Report-Only.

It takes a URL, not a source expression - 'self' and friends mean nothing here.

Syntax

Content-Security-Policy: report-uri <uri>;
Content-Security-Policy: report-uri <uri> <uri>;

What it controls

Where violation reports for this policy are sent.

What it does not control

What is allowed. It never blocks anything and is never itself violated.

Fallback

report-uri has no fallback. It takes URLs rather than source expressions, and a policy without it sends reports nowhere.

Recommended value

Content-Security-Policy: report-uri https://ingest.headerhawk.com/csp/YOUR_INGEST_CODE; report-to csp-endpoint

Copy the full URL from the site’s setup panel in HeaderHawk; the 8-character ingest code is the only site-specific part.
Pairing it with report-to covers both generations of browser. Where a browser understands both, report-to wins and report-uri is ignored - so the two must point at the same place, which HeaderHawk’s single endpoint makes easy.
Reports are matched against the site’s registered domain. A policy served on www.example.com with a site registered as example.com is accepted by the endpoint and then discarded, and the browser sees a success either way.

Examples

Allowed

The report body a browser posts, as application/csp-report:

{
  "csp-report": {
    "document-uri": "https://example.com/checkout",
    "referrer": "",
    "violated-directive": "script-src-elem",
    "effective-directive": "script-src-elem",
    "original-policy": "default-src 'self'; report-uri https://ingest.headerhawk.com/csp/ab12cd34",
    "disposition": "report",
    "blocked-uri": "https://cdn.tracker.example/tag.js",
    "status-code": 200
  }
}

Browser support

Supported everywhere, including browsers that have no report-to support at all.
Marked deprecated in the specification, but no browser has announced removal. Treat it as the compatibility half of a two-directive pair rather than as something to delete.

In a HeaderHawk report

report-uri is never violated - it configures reporting rather than restricting anything. You will never see it as a directive in HeaderHawk.
It does appear inside originalPolicy on every report, which is how you can tell from a report which of your policies produced it.

Getting reports for this directive

Point your policy’s report-uri at your site’s HeaderHawk endpoint and the violations above arrive in the dashboard, grouped as described. The Quick Start sets that up in five minutes, and the integration guides cover the header syntax for each platform.