Using CSP violation reports

  • Revision slug: Security/CSP/Using_CSP_violation_reports
  • Revision title: Using CSP violation reports
  • Revision id: 4724
  • Created:
  • Creator: Sheppy
  • Is current revision? No
  • Comment checkpoint save; page created, 355 words added

Revision Content

{{ gecko_minversion_header("2.0") }}{{ draft() }}

One powerful feature for web site administrators is the support Content Security Policy 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. This article will show you how to configure your site to use the reporting feature, as well as the format of the reports.

Browsers that support CSP will always send a violation report for each attempt to violate the policy you have established.

Note: Servers attempting to send a violation report will not do so if they receive any redirection requests from the server; this prevents attackers from hijacking the violation reports to potentially collect information.

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:

X-Content-Security-Policy: allow self report-uri reportcollector.foo.com

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.

Violation report syntax

The report JSON object contains the following data:

request
The HTTP request line leading to the policy violation; this includes the method, resource path, and HTTP version.
request-headers
The HTTP headers that were sent resulting in a violation of the Content Security Policy.
blocked-uri
The URI of the resource that was blocked from loading by the Content Security Policy. This is not sent in the cast of frame-ancestors violations; in that case, you should assume the blocked URI is the same as the request URI.
violated-directive
The name of the policy section that was violated.
original-policy

The original policy as specified by the X-Content-Security-Policy HTTP header or {{ HTMLElement("meta") }} tag.

The JSON looks like this:

{
  csp-report: {
    request: "GET /index.html HTTP/1.1",
    request-headers: "Host: example.com
                      User-Agent: ...
                      ...",
    blocked-uri: "...",
    violated-directive: "..."
  }
}

The MIME type of the transmitted report is application/json.

Revision Source

<p>{{ gecko_minversion_header("2.0") }}{{ draft() }}</p>
<p>One powerful feature for web site administrators is the support Content Security Policy 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 <a href="/en/Security/CSP/CSP_policy_directives#report-uri" title="en/Security/CSP/CSP policy directives#report-uri"><code>report-uri</code></a> policy directive. The reports are in JSON format. This article will show you how to configure your site to use the reporting feature, as well as the format of the reports.</p>
<p>Browsers that support CSP will always send a violation report for each attempt to violate the policy you have established.</p>
<div class="note"><strong>Note:</strong> Servers attempting to send a violation report will not do so if they receive any redirection requests from the server; this prevents attackers from hijacking the violation reports to potentially collect information.</div>
<h2>Enabling reporting</h2>
<p>By default, violation reports aren't sent. To enable violation reporting, you need to specify the <a href="/en/Security/CSP/CSP_policy_directives#report-uri" title="en/Security/CSP/CSP policy directives#report-uri"><code>report-uri</code></a> policy directive, providing at least one URI to which to deliver the reports:</p>
<pre>X-Content-Security-Policy: allow self report-uri reportcollector.foo.com
</pre>
<p>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.</p>
<h2>Violation report syntax</h2>
<p>The report JSON object contains the following data:</p>
<dl> <dt><code>request</code></dt> <dd>The HTTP request line leading to the policy violation; this includes the method, resource path, and HTTP version.</dd> <dt><code>request-headers</code></dt> <dd>The HTTP headers that were sent resulting in a violation of the Content Security Policy.</dd> <dt><code>blocked-uri</code></dt> <dd>The URI of the resource that was blocked from loading by the Content Security Policy. This is <strong>not</strong> sent in the cast of frame-ancestors violations; in that case, you should assume the blocked URI is the same as the request URI.</dd> <dt><code>violated-directive</code></dt> <dd>The name of the policy section that was violated.</dd> <dt><code>original-policy</code></dt> <p>The original policy as specified by the <code>X-Content-Security-Policy</code> HTTP header or {{ HTMLElement("meta") }} tag.</p>
</dl>
<p>The JSON looks like this:</p>
<pre class="brush: js">{
  csp-report: {
    request: "GET /index.html HTTP/1.1",
    request-headers: "Host: example.com
                      User-Agent: ...
                      ...",
    blocked-uri: "...",
    violated-directive: "..."
  }
}
</pre>
<p>The MIME type of the transmitted report is <code>application/json</code>.</p>
Revert to this revision