report-uri

The report-uri directive tells the browser where to POST a Content Security Policy (CSP) violation report when a page breaks the policy. The browser sends a JSON document to the URL you name, so you can see what the policy blocked.

The directive controls one thing: the destination for CSP violation reports. It does not block, allow, or restrict any resource. When an enforced policy blocks something, or a Content-Security-Policy-Report-Only policy would have blocked it, the browser builds a report and POSTs it to every URL in this directive.

Use the replacement instead:

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

Content-Security-Policy:
    default-src 'self';
    report-to csp-endpoint

Fallback chain

report-uri has no fallback. default-src does not cover it. If you omit it (and report-to), the policy still enforces, but you receive no reports and have no record of what it blocked.

Values

One or more URLs, separated by spaces. Each must be an absolute or relative URL the browser can POST to. Use HTTPS endpoints.

Examples

Content-Security-Policy:
    default-src 'self';
    report-uri https://<Endpoint-ID>.report.centralcsp.com

The browser sends a POST with the Content-Type: application/csp-report. The body is a JSON object with a single top-level csp-report key:

{
  "csp-report": {
    "document-uri": "https://api-next.centralcsp.com/page",
    "referrer": "",
    "violated-directive": "script-src",
    "effective-directive": "script-src",
    "original-policy": "default-src 'self'; report-uri https://<Endpoint-ID>.report.centralcsp.com",
    "blocked-uri": "https://evil.example/x.js",
    "status-code": 200
  }
}

This is a different shape from the report-to payload, which is an array of camelCase objects. See the CSP violation report page for the field reference.

Security notes

report-uri cannot be set through a <meta http-equiv> element; it works only as an HTTP response header. Reports can contain the blocked URL, the document URL, and (with 'report-sample') a snippet of the blocked content, so treat the endpoint as a sink for potentially sensitive data and serve it over HTTPS.

You can collect and aggregate these reports with CentralCSP, and confirm the wiring with the Reporting API configuration checker.

Known bypasses and risks

The directive only reports; it never prevents an attack on its own. A misconfigured or unreachable endpoint silently drops reports, leaving you blind to what the policy blocks. Because the payload includes URLs and optional samples, an over-broad 'report-sample' policy can leak fragments of page content to the endpoint.

Recommendation

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

Content-Security-Policy:
    default-src 'self';
    report-to csp-endpoint;
    report-uri https://<Endpoint-ID>.report.centralcsp.com

Migrate to report-to plus Reporting-Endpoints as your primary reporting path; all three engines now support it (MDN; Firefox release notes). Keep report-uri in the policy only to cover old, unupdated browser versions; any browser that understands report-to ignores it.

Reporting

report-uri is itself the legacy reporting hook: it delivers the wrapped csp-report payload shown above. The modern pipeline delivers the same violations as csp-violation reports through the Reporting API.

Browser support

Widely supported across Chromium, Firefox, and Safari. The modern report-to directive reached Baseline in 2026 and now works across those same browsers, so you no longer need report-uri for Firefox or Safari coverage. Keep report-uri only as a fallback for very old, unupdated browsers that predate report-to.

See also

• report-to directive
• Reporting-Endpoints header
• Content-Security-Policy-Report-Only header
• report-uri vs report-to

Sources

• MDN, CSP report-uri
• W3C, Content Security Policy Level 3
• MDN, Firefox release notes