# report-uri (/en/docs/web-security/policies/content-security-policy/directives/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.
`report-uri` is deprecated in favor of the [`report-to`](/en/docs/web-security/policies/content-security-policy/directives/report-to) directive plus the [`Reporting-Endpoints`](/en/docs/web-security/reporting-api/headers/reporting-endpoints) header, which route CSP violations through the Reporting API, the same delivery pipeline the browser uses for every other report type, instead of a CSP-only POST. Browsers that support `report-to` ignore `report-uri`. Since `report-to` reached Baseline in 2026 and now works across current browsers, keep `report-uri` only as a fallback for very old ones. See [Browser support](#browser-support).
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](/en/docs/web-security/policies/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:
```http
Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com"
```
```http
Content-Security-Policy:
default-src 'self';
report-to csp-endpoint
```
## Fallback chain [#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 [#values]
One or more URLs, separated by spaces. Each must be an absolute or relative URL the browser can POST to. Use HTTPS endpoints.
| Value | Status | Description |
| ----------------------- | ------------- | -------------------------------------------------------------------------------------------------------- |
| One or more report URLs | ⚠️ Deprecated | Destinations the browser POSTs violation reports to. The whole directive is deprecated; use `report-to`. |
## Examples [#examples]
```http
Content-Security-Policy:
default-src 'self';
report-uri https://.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:
```json
{
"csp-report": {
"document-uri": "https://example.com/page",
"referrer": "",
"violated-directive": "script-src",
"effective-directive": "script-src",
"original-policy": "default-src 'self'; report-uri https://.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](/en/docs/web-security/reporting-api/reports/csp-violation) page for the field reference.
## Security notes [#security-notes]
`report-uri` cannot be set through a `` 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](/tools/reporting-api).
## Known bypasses and risks [#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 [#recommendation]
```http
Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com"
```
```http
Content-Security-Policy:
default-src 'self';
report-to csp-endpoint;
report-uri https://.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 [#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](/en/docs/web-security/reporting-api/reports/csp-violation) through the Reporting API.
## Browser support [#browser-support]
Widely supported across Chromium, Firefox, and Safari. The modern [`report-to`](/en/docs/web-security/policies/content-security-policy/directives/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 [#see-also]
* [report-to directive](/en/docs/web-security/policies/content-security-policy/directives/report-to)
* [Reporting-Endpoints header](/en/docs/web-security/reporting-api/headers/reporting-endpoints)
* [Content-Security-Policy-Report-Only header](/en/docs/web-security/policies/content-security-policy/report-only)
* [report-uri vs report-to](/en/blog/report-uri-vs-report-to)
## Sources [#sources]
* [MDN, CSP report-uri](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/report-uri)
* [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)
* [MDN, Firefox release notes](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/149)