SITE UPDATES |

HTTP Header Security Analysis

This article shows the analysis of the technology used by the worlds top websites by querying the data on the usage of HTTP Header security controls.

This is a breakdown of the HTTP Header security features that have been developed by different organizations. These controls can utilize features in the web browser to protect the user from browser-based exploits. Unfortunately, it is clear from the results the application of these security controls is at best minimal and closer to non-existent in the top websites.

HTTP Only flag on the Set-Cookie header

Total Set-Cookie Headers: 682598
Cookies with HTTP Only Flag set: 88442

HTTP Only flag on the Set-Cookie header

HTTPOnly is not a HTTP Header, but a property of the Set-Cookie header. It indicates to the browser this cookie should only be accessed over HTTP and not from client side scripts. This is mitigation against XSS Attacks, where the evil client-side javascript would attempt to steal a session cookie.

The browser must support the HTTPOnly flag for this mitigation to be effective.

Full details of the supported browsers and implementation of the HTTPOnly Cookie in dot NET, Tomcat, and PHP is all covered at the wikipedia page.

X-Frame-Options HTTP Header

Number of sites with X-Frame-Options Header: 9009

Number of sites with X-Frame-Options Header

This header informs the browser if a web page is allowed to be framed in another web page or not. The main purpose of this protection is to prevent malicious sites from conducting a click-jacking attack against the user.

There are two parameters available to the X-Frame-Option. These are;

SAMEORIGIN: Allows a page to be framed if it is within a page within the same domain.

DENY: is a more restrictive parameter. This parameter simply prevents the page from being framed.

X-XSS-Protection

Number of sites with X-XSS-Protection enabled: 25423

Pie Chart showing Number of sites with X-XSS-Protection enabled

This header is only utilized by Internet Explorer 8 and will turn on the built in cross site scripting protection. The reason for this is that IE 8 was shipped with the cross site scripting protection turned off by default as they feared that some web sites may break if it was turned on.

To turn the protection on the server sends the header as this:

X-XSS-Protection "1; mode=block".

X-Content-Security-Policy

Number of sites with this enabled: 36

Pie Chart showing number of sites with X-Content-Security-Policy set

This is a policy that informs the browser how content can interact with your website. The policy includes content such as videos and javascript.

For example specifying "allow 'self';". Specifying this will prevent the page allowing the execution of javascript from third party sources. All javascript will have to be sourced from the same domain. This helps prevent cross site scripting attacks as it raises the bar and makes an attacker have to run the code from our domain name rather than any third party web site.

If specific third party resources are required, settings are available to whitelist specific domains and file types.

In conclusion

Mozilla has provided a lot of detail on this security feature. Furthermore, there are a lot of good reasons to use the X-Content-Security-Policy header. Unfortunately, it seems most web / system administrators are not aware of it or just do not care....

These stats have been quickly pulled together from the data we have been processing. Some like the x-content-security-policy total of 36 seem a bit off, but I have double checked and re-ran the query. No guarantee to accuracy is provided, but its pretty close.

Next Level Your Technical Network Intelligence

Use Cases and More Info

  • 13 Vulnerability Scanners
  • 17 Free DNS & Network Tools
  • 4+ Billion Records of DNS / IP data