Whilst we already have support for CSP reports over at Report URI, there is another potential source of information about XSS attacks that may be attempted or happening on your site. The X-XSS-Protection header allows you to configure the XSS Auditor, deem what action it should take and request that the auditor send reports if action is required. We now support XSS Auditor reporting on Report URI!
The XSS Auditor
The XSS Auditor runs whilst HTML is being parsed and attempts to find reflected XSS attacks against the user. If it finds a possible attack the Auditor can take no action, it can filter what it thinks is the attack payload or it can refuse to render the page at all. You can find more details about the XSS Auditor which is present in Chromium and WebKit so there is a good share of browsers that have one.
Configuring the Auditor
The default configuration for the XSS Auditor varies depending on which version of which browser you're using, of course, but configuring it is easy enough. You can control the auditor with the X-Xss-Protection header with a few simple values. You can read more detail about configuring the auditor in my blog post Hardening your HTTP response headers and you can test to see if your site, or any other site, has it deployed properly using securityheaders.io. No matter which configuration you use, as long as you have the auditor enabled, it can send reports about the action it takes.
X-Xss-Protection: 1; mode=block; report=https://{subdomain}.report-uri.com/r/d/xss/enforce
XSS Reports
Whilst the original purpose of CSP was to defend against XSS attacks, and it can do that very sucessfully, if you have both CSP and XXP (X-Xss-Protection) deployed you can benefit from an even better level of protection. There's no reason to think you don't need one if you have the other, leverage the protection of both!
Whether you do or don't have CSP deployed, you can deploy XXP and have the Auditor stop attacks before they even take place. If CSP is a last line of defence in the browser then XXP is an additional, penulitmate line of defence. With the auditor configured, if it sees any kind of reflected XSS attack on your site it will send a report that looks like this.
"xss-report" : {
"request-url":"https://scotthelme.co.uk/introducing-xss-reporting-to-report-uri/?search=%3Cscript%3Ealert(123);%3C/script%3E",
"request-body":""}
}
This is a great report to receive and it will tip you off about a likely issue on one of your pages. The good thing about the report is that it won't be sent if the browser doesn't find the content of the GET parameter reflected somewhere in the page, so the false positive rate should be fairly low. You might see some novel attacks against your users, find some nifty XSS payloads or just rest assured knowing that if the browser thinks there's a problem then it will tell you. Deploy it alongside CSP, before CSP or after CSP, it doesn't really matter, but it's available now and you should go check it out.
Support
The XSS Auditor can send reports from Chromium and WebKit based browsers which gives us a pretty high level of visibility. WebKit will happily send those reports right now but Chrome does have a small interruption in service at present. You can read more in the Chromium Bug but Chrome will being sending reports again during April, so we will be back on track there. The great thing about reporting mechanisms like this is that we can still get value from the feature even without 100% browser support. There are a lot of WebKit browsers out there and they may be able to tell you something useful.
Other Updates
We've also released a few other features here and there over the last couple of months so I wanted to detail those too. The list is far from exhaustive but here's a few:
When filtering your repors on the Reports page, the filter is now reflected into the URL. This means you can bookmark/share/save filters for more convenient use in the future. Back/forward navigation also works as expected.
After the recent update that introduced wildcard queries in the hostname and path fields, we've also introduced a 'not' filter that does exactly what you'd expect.
We've made some improvements to our filtering for inbound reports. There's now less noise making it through to your account and we have special handling in place for a few browser bugs so reports will make more sense overall.
There have been countless UI tweaks and improvements to make the browsing experience better including series highlighting and toggling on the graphs page, better sorting on the Reports tables, Team invite emails, performance improvements and much more!
After launching XSS Auditor Reporting today we've started our 7 day countdown to our next feature launch which is going to be a big one. I'm really excited about the launch next week and I'm hoping everyone will love the new feature as much as we do!