Usage of http security headers

Web applications suffer from all kinds of attacks against the browser. This is partly due to the fact that the browser is not aware of what is normal behavior and what are normal code sources of the app that runs on it. The result is that there are numerous issues with Cross-Site-Scripting, Click-jacking, redirecting encrypted connections to plaintext channels, cookie theft with JavaScript, etc.

The good news is that there are means to counterpane those attacks. The last years, quite some possibilities have emerged to configure the HTTPS-connection properly. These have the form of HTTP-headers: information that the web server provides to the browser in order to improve security. A summary of these headers (based on this blog) is given below. In addition, counts have been carried out on over 10.000 websites to assess the 'market share' of each header.

•  50% - Cache-Control - Disable caching for confidential information
•  23% - X-Frame-Options - Block click-jacking. (deprecated, will be replaced by the Frame-Options directive in the Content Security Policy)
•  21% - Strict-Transport-Security - Enforce HTTPS and add your domain to Chrome’s preload list. HSTS enables a web app to instruct browsers to allow only HTTPS connections to the origin host, to internally redirect all insecure traffic to secured connections, and to automatically upgrade all insecure resource requests to be secure.
•  17% - X-Content-Type-Options - Prevent MIME-based attacks, don't let the browser determine what type of content you provide.
•  13% - X-XSS-Protection - Make your web app more robust against XSS (deprecated, will be replaced by the Frame-Options directive in the Content Security Policy)
•  4% - Content-Security-Policy - white-list specific sources and endpoints and be informed of policy violations. This is the new standard.
•  0% - Referrer-Policy - Governs which referrer information should be included with requests
•  0% - Public-Key-Pins - advise the browser what certificates to expect.

Special attention should be paid to the Content-Security-Policy. This is a new header (see specification) that will eventually replace most of the existing ones and offers a fine-grained model to manage the security configuration of a web application. Although used in only 4% of the websites (2017), I expect this share to grow and become dominant.

25% of web sites don't protect cookies

It turns out that 64% of websites do not use any HTTP security header at all. For cookies, specific directives (such as ‘httpOnly’ and ‘secure’) can be set to prevent JavaScript to access the cookie information. Websites mostly use cookies to to store some identifier or session ID. Therefore, one should expect this cookie to be secured. In reality, 25% of websites that set a cookie do this without any HTTP security header and without any cookie security attribute.

What can you do

If you are new to this, focus on the Content-Security-Policy. It's an emerging and accepted standard which will replace most of the other headers.

Although some of the HTTP security headers are deprecated, they are still effective and used a lot. Quick wins are Cache-Control, X-Frame-Options and Strict-Transport-Security. And don't forget to make your cookies ‘httpOnly’ and ‘secure’! For more info, see the OWASP Secure Headers Project for more info.

Check your headers in detail at securityheaders.io.

A basic check on http security headers in included as a no-brainer in the internet-security-scan.