Using CSP violation reports

Draft
This page is not complete.

One powerful feature of Content Security Policy for web site administrators is the support it offers for generating and delivering reports describing attempts to attack your site. These reports are delivered by HTTP POST requests to one or more servers you specify using the report-uri policy directive. The reports are in JSON format, using the default JSON UTF-8 encoding for non-ASCII characters. This article shows you how to configure your site to use the reporting feature, as well as the format of the reports.

Browsers that support CSP always send a violation report for each attempt to violate the policy you have established if the policy contains a valid report-uri directive.

Enabling reporting

By default, violation reports aren't sent. To enable violation reporting, you need to specify the report-uri policy directive, providing at least one URI to which to deliver the reports:

Content-Security-Policy: default-src 'self'; report-uri https://reportcollector.example.com/collector.cgi

Then you need to set up your server to receive the reports; it can store or process them in whatever manner you feel is appropriate.

Note: prior to Firefox 23, the X-Content-Security-Policy header was used. This header will be deprecated in the future.

Violation report syntax

The report JSON object contains the following data:

document-uri: The URI of the document in which the violation occurred.
referrer: The referrer of the document in which the violation occurred.
blocked-uri: The URI of the resource that was blocked from loading by the Content Security Policy. If the blocked URI is from a different origin than the document-uri, then the blocked URI is truncated to contain just the scheme, host, and port.
violated-directive: The name of the policy section that was violated.
original-policy: The original policy as specified by the Content-Security-Policy HTTP header.

Sample violation report

In the CSP specification, an example regarding violation reports is given. Another sample will be presented and explained here.

Let's consider a page located at https://example.com/signup.html. It uses the following policy, disallowing everything but stylesheets from cdn.example.com.

Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports

The HTML of signup.html looks like this:

<!DOCTYPE html>
<html>
  <head>
    <title>Sign Up</title>
    <link rel="stylesheet" href="css/style.css">
  </head>
  <body>
    ... Content ...
  </body>
</html>

Can you spot the mistake? Stylesheets are only allowed to be loaded from cdn.example.com, yet the website tries to load one from its own origin (https://example.com). A browser capable of enforcing CSP will send the following violation report as a POST request to https://example.com/_/csp-reports, when the document is visited:

{
  "csp-report": {
    "document-uri": "https://example.com/signup.html",
    "referrer": "",
    "blocked-uri": "https://example.com/css/style.css",
    "violated-directive": "style-src cdn.example.com",
    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
  }
}

As you can see, the report includes the full path to the violating resource in blocked-uri. This is not always the case. For example, when the signup.html would attempt to load CSS from https://anothercdn.example.com/stylesheet.css, the browser would not include the full path but only the origin (https://anothercdn.example.com). The CSP specification gives an explanation of this odd behaviour. In summary, this is done to prevent leaking sensitive information about cross-origin resources. Note, that even the specification got this part wrong in its example on violation reports (blocked-uri should be "https://evil.example.com").

Using CSP violation reports

Enabling reporting

Violation report syntax

Sample violation report

See also

Document Tags and Contributors