5 years ago
Stuart Larsen #article
‘report-uri’ is a nifty feature built into content-security-policy that allows website owners to get insight on their deployed policy.
Content Security Policy issues can be complex to debug. The policies are evaluated on the client's browsers, which can be tough to glean information from when there’s a failure.
If we think of the flow:
If the picture stopped here, it would be very difficult for website owners to know that content-security-policy has broken their website (or that someone is exploiting their website), and on what browsers, and under what conditions.
So content-security-policy has a concept called ‘report-uri’ where a JSON body will be sent if the content-security-policy blocked a piece of content.
The report is sent via an HTTP post, with a JSON body that looked like the following (this is a real CSP violation report from my production website):
Figure 1: Sample Content-Security-Policy report-uri report
From this we can see that the violated directive was "img-src" and that the blocked-uri was the domain https://www.google-analytics.com
. It means I’m no longer getting google analytics data because of content-security-policy!
To fix this issue I need to add https://www.google-analytics.com
to my img-src. (Or use a tool like https://csper.io to do this for me.)
A version of the original policy, along with other useful information such as the "referrer" can also be found in the report.
The HTTP post also contains the UserAgent HTTP header, which can be extremely useful for debugging issues that only occur on one type of browser.
The main goal of content-security-policy is to help protect against cross site scripting. (An introduction to CSP and XSS can be found here: An Introduction To Content Security Policy.
You can also use report-uri to detect this naughtyness.
There’s a neat new feature of CSP called ‘report-sample’, you can attach it to your policy like this:
Figure 2: report-Sample on script-src directive
When report-sample is specified on the script-source or style-src, 40 characters of the violating script will be included.
So when I manually simulated an XSS on my website I got something like the following:
Figure 3: XSS content-security-policy report-uri report
I can see that someone was able to perform an XSS alert(document.cookie) on my webpage at https://csper.io/evaluations/5e4442eb6cb5f0e33a04b992
. At this point if it was a real XSS I would go to that page and investigate anywhere there could potentially be an XSS. (the line-number and column-number in the report are handy). Technically you could use CSP to block XSS’s, it’s way better to fix the underlying issue and only use CSP for monitoring and defense in depth.
Setting up report-uri in a policy is pretty simple. It’s just part of your content-security-policy that gets sent in the http header (report-uri can not be used in an html meta-tag).
For example:
So now all violation reports will be sent to https://myawesomewebsite.com/my-personal-csp-endpoint
You can use it to generate your original CSP policy with no effort. There are tools such as Csper that use report-uri to generate your content-security-policy for you. You can set your content-security-policy to "report-only" mode, so that users of your website will send violation reports, but not actually block anything.
Csper then takes all of these violation reports, aggregates them together (there can be a lot depending on traffic), and provides recommendations on how to build a policy in minutes. (An example of building a policy using this method can be found in this video.
Figure 4: Content-Security-Policy builder through report-uri
report-uri is technically deprecated, but the replacement (report-to) isn’t supported by most browsers. You can either support both, or wait till report-to is more widely supported by all browsers.
Are there any problems with reports that make it difficult?
One of the tough things about reading CSP reports is that they can be very vague and confusing. Browser extensions, ISPs, addons can inject content into web pages that CSP will block. Which is great (sometimes), but it can lead to very confusing reports.
There’s a very cool collection of weird CSP reports here. A bunch of people in the security community came together to decode a number of the confusing reports.
Thanks for reading! If you have any questions please feel free to reach out stuart@csper.io
Csper has the tools to help you understand, deploy and manage your content security policy. Get started in minutes. Report aggregations, classification, analysis, alerting, realtime and more. Free 14 day trial.