.png){kind=small}
In our previous blogpost about Content Security Policy (CSP) we promised to have another one about reporting and mentioned report-uri. Turns out that report-uri was deprecated in Content Security Policy Level 3:
The report-uri directive is deprecated in favor of the new report-to directive
In this blogpost we will check how report-to works and the main differences from report-uri. We will also check out the new Reporting API!
Use case
Imagine that we have a page with three iframes that link to Mozilla's website and subdomains, e.g. the following simplified HTML snippet:
How can we implement a CSP that allow these iframes to be loaded?
As we have seen in the previous blogpost we need to set the following CSP header value:
Content-Security-Policy: "default-src ‘self’; frame-src https://mozilla.org https://*.mozilla.org;"
However, if some errors arise we might want to report them properly so we can act on them. Let’s say that we only included Mozilla’s subdomains and forgot to add https://mozilla.org to the allowed domains:
Content-Security-Policy: "default-src ‘self’; frame-src https://*.mozilla.org;"
This should create an error. Let’s learn how to report it!
BEFORE: Using report-uri (*DEPRECATED!*)
report-uri receives a endpoint, e.g
Content-Security-Policy: … ; report-uri <report-endpoint>
Let’s use a Node express.js server to test this. If we set the CSP header from the use case (where we expect to have an error) and use it on the /content route:
Notice that we are telling the browser to send all report errors to /report route using report-uri. Let’s add a /report route to check those errors:
This will fail for the last iframe (https://mozilla.org) as expected and we will get a POST on /report route with the following details:
There is plenty of information here to be processed and used to help to solve browser issues that can appear. We know exactly what was the policy that reported the error and what failed.
report-uri is widely supported in most browsers. However, it is not using a consistent reporting framework and that is the main reason why the Reporting API was created and the new CSP key report-to was created.
Hint
Some browsers request the Content-Type as application/csp-report, others as application/json so in order to use it we have to setup some configurations on our express server:
Using report-to
report-to will replace report-uri soon, but currently it is only supported on Chrome (> version 70) and Android.
Instead of a URI, it receives a groupname:
Content-Security-Policy: … ; report-to <groupname>
and it needs an additional header to be set, Report-to:
We can set multiple groups with multiple endpoints, which is useful because we can have the CSP group that will report CSP errors, the network group to report network errors, and so on.
Endpoints can have priorities (for failover) and weights (to distribute load) and a caching value (max_age) is required to be set.
The body received from report-to is also different from what we got with report-uri, but it tells essentially the same story:
Note: In this case type is csp but if we had a network error it would be nel and for a certificate error it would be hpkp. Check some examples in the sample reports from the Reporting API.
Hint
In order to use report-to the Content-Type has to be application/reports+json. We also need to setup our express server to serve HTTPS with a valid certificate, otherwise you can’t test/use it.
The New Reporting API
The working draft explains it better than me but let’s sum up some key points about the Reporting API:
There are some differences between report-uri and report-to, mainly related to how to specify it and the extra Report-to header but in the end the data received is similar. However, the Reporting API opens a new world of possibilities to grab all kinds of errors in the browser.
Want to know more? We will cover CSP's strict-dynamic and nonce in another blogpost, follow us and stay tuned!
