It has been over a year since the last analysis on security headers was run. The current state of security header usage will be presented along with a differential analysis of the previous run from October 2014. While no architectural changes to the scanner were made this time, this will be the last run done with this code base.
A new scanner is currently under development to gain more information from not only the top URLs but from the resources they source in.
The scan took place October 27th 2015. Using the latest Alexa Top One Million Web Sites. For results, we had a total of 3,105,927 responses. Firefox having 1,552,434 and Chrome having 1,553,493. Firefox had 940,174 HTTP and 612,260 HTTPS responses. Chrome had 941,149 HTTP and 612,344 HTTPS responses. A total of 25,254,834 headers were collected and processed by our scanner in roughly two hours.
Comparing our previous scan which took place in October 2014, there were 647,175 Firefox and 647,813 Chrome URLs that overlapped with this scan. As a reminder, added headers are calculated where the header existed in the latest run where it did not exist in the previous run. Provided that the URLs existed in both runs. For removed headers, the process was the same, only reversed. The only catch is to ensure that conflicting headers were not added to the count. Conflicting headers are when the server sends two header names back with different, conflicting values. These were removed from all comparisons.
Additionally, ‘invalid’ values are included in all comparison counts, so consider a small margin of error. We left the invalid values in as they still give a glimpse into what sorts of changes web site operators are attempting to implement, whether or not they were correct in it. When calculating the changes, queries were done to ensure case insensitivity and whitespace trimmed.
This header continues to see very wide adoption. Oddly, 390 sites were found to set 0; mode=block which, as previous readers may remember, is an invalid setting. Upon closer inspection this appears to be a bug (or feature) of non-english phpbb3 hosting forum sites, changing the 1 to zero if the chrome user agent is detected. This issue was found primarily in a Sudanese and French shared forum hosting site which appear to be the same underlying company. The setting of 1; mode=block continues to be the most common setting.
X-XSS-Protection had one of the least amount of additions. Almost all changes were adding or changing a report-uri value. Only two sites went from filtering to blocking and one site went from blocking to filtering.
XCTO continues to have a strong number of adopters with invalid settings primarily being the inclusion of invalid characters such as quotes.
XCTO had the second largest number of additions this time around with 8,689 for Chrome and 8,718 for Firefox. Only a single site changed the value from an incorrect setting ‘nonsniff’ to ‘nosniff’. Once again we see the same forum hosting site as causing a large number of XCTO headers being removed.
XFO set to same origin continues to be the most common setting with 74,698 for Chrome and 74,756 for Firefox. It also continues to be plagued by one of the largest number of invalid settings, 646 for Chrome and 644 for Firefox.
A rather amazing 18,110 sites added X-Frame-Options this time around compared to the previous run a year ago. Most of the newly added headers were set to SAMEORIGIN, which as seen in the previous chart is by far the most popular setting. For changes, 167 sites moved to SAMEORIGIN, 56 went to DENY, 28 went to ALLOW-FROM and 43 to goforit/allowall.
The STS header can now be found on over 15,800 sites of the current top one million sites. Previously the number of sites using this header was only around 4,400. There are now more sites including subdomains in their settings than sites using STS a year ago. Around 2,000 sites elected to be a part of the browser preload list. Unfortunately 400-600 of those sites did not meet minimum requirements for their settings (must includeSubDomains, must have a value greater than 10886400 seconds).
Changes for Strict-Transport-Security, as with all STS stats, include only HTTPS URLs. Over 5,500 sites added the header compared to a year ago. 780 removed the header, interestingly the majority of sites that removed it had long values set. It would be interesting to know if this header was causing issues and was removed due to it. 75 sites went from a larger value to a smaller value. 137 sites went from a smaller value to a larger one. 72 added the includeSubdomains directive, where 55 removed the directive.
The ACAO header also continues to be plagued by large number of invalid settings. However its usage has almost doubled from last year. The wildcard setting continues to be the most popular setting.
The changes this time around reflect what we saw last year, except with the added and removed values doubled. Last year 3,000 sites added, 700 removed, 400 changed and around 5,000 stayed the same.
Last year only around 800 of the top one million sites were using CSP, now we have around 2,600, almost exactly a 3x increase in adoption. While the total is still small this is a welcoming development. Around 1,900 sites are still unfortunately allowing unsafe script. As a reminder, the ‘bad script’ count is old X-CSP directives (inline-script) being used incorrectly in the newer CSP header.
We are also seeing newer directives and features of CSP 1.1 and 2.0 being used. 73 sites are now using the reflected-xss directive, with 64 set to block and nine set to filter. Ten sites have been configured to use nonce values for the script-src directive.
Around 960 sites added the CSP header when comparing the same URLs last year. A lot of the changes were due to adding additional sites to the various allowed sources policies.
Over 700 sites are still using these deprecated headers. We are seeing roughly the same number of X-Content-Security-Policy headers this year as we saw of Content-Security-Policy headers last year.
Unfortunately, we are still seeing sites adding these deprecated headers, with more being added than removed. This is strange given that this header was deprecated last year as well and sites really should not be even considering to add this header. Perhaps this is to support older browsers who still do not yet support Content-Security-Policy.
Over 274 sites are now using the Public-Key-Pins header, this is quite a significant increase from last year where we only saw five. A total of 27 sites have set the Public-Key-Pins-Report-Only header.
Overall, it’s good to see such a large number of sites adding these headers. The most impressive change would have to be the rate of adoption of Content-Security-Policy. Invalid settings continue to be a problem and website administrators are urged to review our guidelines on properly configuring and testing security headers.
The next time we run this analysis we will be dropping Firefox user-agent tests in favor of using only Chrome. This is because we will begin doing this analysis with a real browser to get even more data. While it was nice to have the differences between the two, the amount of work necessary for reporting on the new data is not worth the effort required.