I've just pushed another update to https://report-uri.io that brings quite a few new features and improvements.
This update brings about the second significant set of changes to https://report-uri.io since being launched earlier this year. The first major update brought tweaks to the layout, new features like custom reporting addresses and time zone selection along with the ability to completely delete all of your report data and much more. This second update brings about yet more significant updates and the introduction of new features too! They should make your experience using the site much easier and present you with more information in a less complicated UI. I'm really excited to finally release this update as it represents many weekends and late nights of work over the last few months. Enjoy!
UI update
The coloured headings in places like the reports and graphs pages are now gone and there is a much cleaner theme throughout. These colours didn't really represent anything so their removal hasn't had any negative impact. The UI is much more consistent throughout.
before
after
Flagging report-only violations
One thing that's been apparent for some time with incoming reports is the need to be able to determine whether the report was generated from a report-only policy or an enforced policy. With this update you can now see, at a glance, what type of policy caused the report to be sent in the Action column.
The Action column now indicates that a particular report was triggered by a report-only policy with the blue indicator or that the report was triggered by an enforced action when the report-only indicator is greyed out. You no longer need to look at the raw data to try and establish this.
How to set the report-only flag
To mark reports with the new report-only flag you will need to add a parameter to your report-uri directive in the policy itself. In the Setup page you will now see two report-uri values that you can use, one for enforced policies (Content-Security-Policy) and one for report only policies (Content-Security-Policy-Report-Only). Unfortunately this means that you will need to maintain the appropriate value in each header but I have raised a bug in the specification about this. For now, it seems that the site admin will have to maintain the appropriate value in the header.
CSP graph changes
Previously, CSP violations were only graphed by their total count. This made it difficult to tell what a spike in reports was caused by. With this update all CSP reports will now be graphed by their effective-directive value so you can get a better feel for exactly what is causing your violations.
before
after
Note: The above graphs show different datasets.
Raw report data is hidden
The raw report data for CSP and HPKP reports is now hidden by default and can be expanded if you want to view it. This makes the tables much more compact and easier to read!
before
after
This is one of those changes that seemed obvious once I started getting a lot of data: URI violations that included the base64 encoding of a resource and once my CSP started to grow as shown above. Little changes like this should make the site much easier to use and to extract valuable data from.
Browser identification
The CSP and HPKP reports now also show which browser they were generated by. This information is extracted from the User Agent string and nothing else is stored except the name of the browser. The current supported browsers are Chrome, Firefox, Safari, Opera, Internet Explorer and Edge. Browsers that can't be identified or are not in the supported browser list are indicated with a ? icon.
In some circumstances we can extract additional information about the browser and if we do, you can hover over the ? icon to see it.
The list of supported browsers will be expanded and introduced in small patches over the coming weeks and I'm also considering if I should indicate the platform the report was generated on. This would allow you to distinguish between Chrome on Android or Windows and Safari on Mac or iOS for example, something that could be quite important. To implement this feature I obviously have to analyse the User Agent string provided by the browser that sends the report. I want to make clear that I do not store the UA string. I extract the name of the browser that sent the report and store just that, nothing more.
Pagination
The pagination of reports now works more reliably. There were certain circumstances where the ordering of reports wasn't quite right when you paginated through them. This has now been fixed.
CSP Analyser updated
The CSP Analyser will now follow redirects until completion and not output details on policies presented along the way. It displays the full address that the policy being displayed was received from and there are new indicators by each policy value to provide additional feedback.
before
after
There is also a new link that you can copy which will take you to the results page directly without having to type your address in. It's quite handy if you want to pass it on to others.
CSP Builder bug fix
The CSP Builder had the 'none', 'all' and 'self' options missing on the Manifest Source section. These have now been added.
HPKP Analyser udpated
The HPKP Analyser has had similar changes to the CSP Analyser. It will now follow redirects until completion and output details of the policy at the end of the redirects. The colours have also been changed to remove the negative indication that red seemed to give. I now also output details of all domains in the SAN for the current pin.
before
after
Further to this the analyser will also output information about root pins and that includes root pins not in the current certificate chain. If multiple CA roots are pinned you will now see information about them. The GitHub HPKP policy is a good example of this.
before
after
Additional CSP filters
I've added a couple more entries to the CSP filter list to drop reports where the blocked-uri is a localhost address.
The filters really help cut down the amount of noise in your CSP reports and I highly recommend using them all. Without them, you can end up with pretty large numbers of reports that are totally useless and drown out the really valuable ones.
Privacy Policy
After receiving a lot of questions regarding my ability to collect data on visitors to sites that use https://report-uri.io, I wanted to introduce the start of a Privacy Policy. Right now it's very simple but I just wanted to get something in place to make my position clear. I do not need, or want, to collect identifiable information on visitors to your site. It's data that I don't want to be responsible for and as the saying goes, if I don't have it, I can't lose it. At present, I extract the name of the browser used to send each report and that's it. This is purely so you can see that if you got 10k reports for a script violation that all came from Safari, you have more information to debug the problem. The User Agent string is never stored and neither is the IP address of incoming reports. This is the reason that all historic reports in the dashboard will show as an 'unknown' browser, because this information was never kept so I can't go back in time and extract it.
Further updates
The next big round of updates will be under way soon and you can always get a sneak peak of anything that's coming on the test site, https://test.report-uri.io. The test site is a completely independent entity and there is no cross over between account credentials or data. You will need to sign up and treat it like a completely different site. Updates already being considered include:
- More browser types to be identified and displayed.
- Identify the platform the report came from along with the browser.
- Normalisation of incoming CSP reports to further reduce noise.
- Additional filters could include common malware domains.
- Filter reports based on the host the violation came from (multi site users).
- Filter reports based on effective-directive value.
- Improve the Top 10 pages.
- Custom, user configured flags in addition to reportOnly.
This is just my own list but of course, you guys out there may have some ideas, which brings me on to...
Feedback
As always, please let me know of any issues and further suggestions in the comments below. It's always great to hear from people who use the service so even if you just want to link to your site and say that you're signed up, it'd be great to know. Some of the best suggestions I've had to improve the site have come from people and businesses that use it day to day. You guys are the people I built this service for and the best placed to tell me how to make it better. Don't be shy!