There are a lot of security headers out there, and due to a recent scanby @einaros we can now build some statistics on the use of these headers in Norway. The result is disappointing.
Data
In the the list at http://dotno.indev.no/ there seems to be about 83,000 Norwegian domains. The website provides a search interface giving the number of hits for the queried headers. The UI allows search for header names and substring matches for values. To search for apache servers you could use the query "server:apache".
Clickjacking
Clickjacking is (partially) mitigated by using the X-Frame-Options header. This header was introduced in IE8, but is now supported across the most popular modern browsers.
| X-Frame-Options | 0.69% | 569 |
|---|
Clearly a very disappoitning number.
X-XSS-Protection
Modern browser (at least IE and Chrome) have built-in filter intended to stop XSS-attacks. These filters can be controlled by using the X-XSS-Protection header. A value of 0 means disable. A value of 1 means enable. Additional a mode can be set instructing the browser how to handle a detected attack.
| Sites setting X-XSS-Protection | 0.78% | 643 |
|---|---|---|
| Sites setting X-XSS-Protection:1 | 0.66% | 544 |
| Sites setting X-XSS-Protection:0 | 0.12% | 99 |
A very low percentage of sites are actually setting the header, and 15.4% of those setting it, actually disable the filters. Out of the sites setting the header to 1, all set mode to "block".
Content-Security-Policy
This is a modern header allowing the server to set a policy for the browser. It instructs the browser whether it's allowed to run inline JavaScript, which domains it can download images, script, css etc. from and more. Finding a proper policy for a site, can be challenging.
| Sites setting Content-Security-Policy | 0% | 0 |
|---|
None. Zero. Null.
Cross Origin Resource Sharing (CORS)
The Access-Control-* headers allow JavaScript in browser to load data across origins. This is normally regulated by the Same Origin Policy, but these headers provide a way to relax this policy. If a server sends "Access-Control-Allow-Origin: example.com" in a response, tells the browser that if the current URI has a domain name of "example.com", it is allowed to access data from that domain. Specifying "Access-Control-Allow-Origin: *" allows any domain to use the data. "Access-Control-Allow-Credentials: true" tells the browser it's allowed to include cookies in the request.
| Sites setting Access-Control-Allow-Origin | 0.62% | 511 |
|---|---|---|
| Sites setting Access-Control-Allow-Origin:* | 0.56% | 462 |
| Sites setting Access-Control-Allow-Credentials:true | 0.06% | 49 |
| Sites setting Access-Control-Allow-Origin:* and Access-Control-Allow-Credentials:true | 0.05% | 41 |
The last combination is insecure and disallowed by the spec. It means any site can access data on the given domain using the currently logged in user's cookies.
Cookie flags
There are two cookie flags that are interesting from a security perspective. If the Secure flag is included in a response over HTTPS, the browser is instructed to only send the cookie over HTTPS connections. The HttpOnly flag instructs the browser to hide the cookie from JavaScript. This is intended to stop XSS attacks from stealing the cookie.
| Sites setting cookies | 44.46% | 36652 |
|---|---|---|
| Sites with cookie name containg session | 17.58% | 14493 |
| Sites using the HttpOnly flag | 11.99% | 9884 |
| Sites setting cookies over SSL | 1.01% | 833 |
| Sites setting the secure flag | 0.3% | 247 |
68% of sites setting a session (based on query for cookies with a name containing session) are using the HttpOnly flag. Out of the sites setting cookies over SSL, only 30% use the Secure flag.
Conslusions
All in all these are disappointing results. Especially the use of the cookie flags and the clickjacking header is much lower than expected.
