HTTP Security Headers

When your web browser requests a web page from a web site, as well as returning the web page, the web server will send a lot of extra information back about the file its sent, and how the web server wants you to use it. These headers can be seen on your developers tools in your browser (accessed by pressing F12 in most browsers - before your load a site). The HTTP headers for this website are shown below:

Some of these headers are just extra information about the file (the size, what format the page is...etc), but there are also some security headings that I have turned on. Most of these are standardised and nearly all of them enjoy wide spread support in most modern browsers. For example the X-Frame-Options header is set to deny, which means the browser will not allow your site to load as part of a frame from another site (which is a security risk).

Each of the security headers you may want to consider are listed here:

• Cookie Security Headers
• Server and X-Powered-By
• X-Content-Type-Options
• X-Frame-Options
• X-XSS-Protection
• Strict-Transport-Security (aka HSTS)
• Content Security Policy (aka CSP)
• Public-Key-Pins (aka HPKP)

Some of these headers, require nothing more than adding a setting to your web server config, and can often be forgotten about after that. Some require a bit more thought before turning on and you should understand them properly before setting them up on your site. Any risks are clearly highlighted in each of the above pages.

The SecurityHeaders.io website by Scott Helme is a great tool for seeing what you do have set already, and what you maybe should consider. Just plug in your website address, and it makes a quick call and displays the results in a nice colour coded page. You can of course see the headers in your browser easily enough, but the tool tells you not only what your website has set already but also headers you possibly should have set. Do be aware again of the risks on some of these settings before you turn them on but the links there and above do explain these risks.

Web server support is mostly not an issue as most servers had the ability of setting HTTP Headers and, as these headers are intended for browsers, there is usually nothing further for a web server to do to, other than to send them.

Web browser support is pretty strong. Some of these have been around for a while so are supported by most browsers. Some of them (particularly HSTS, HPKP and CSP) are newer, but support is quickly rolling out across the browsers. Most of the headers will be ignored without browser support, but CSP in particular may cause issues without browser support so should be used with caution for now.

As with all settings, you should understand the headers before you turn them on. It is possible to block access to your website if some of these are configured incorrectly, and if you set the headers really badly with a long timeout period, then they may be cached in your visitors browsers until that timeout period expires!

However, with that word of caution out of the way, most of these headings are not as dangerous and some of these give a high degree of security for a a very small up front investment to set this up.

The other downside is that if a browser does not support these headers, then they obviously will not offer the protection to those users. However older browsers have other security issues as well, so the best you can hope for is that your users are using newer browsers. At least until Evergreen browsers are the norm!

Finally, these security headers are set on every resource call (even though most are only needed for the HTML resources) so there is a small bandwidth wastage with setting a large number of HTTP headers. CSP in particularly can become quite big depending on the policy you use. Headers are also not compressed with gzip like the body contents (though HTTP/2 will change that) so these bytes can affect performance. Personally I think most of the headers are small and so worth the tiny extra bandwidth usage.

Setting HTTP security headers is one of the easiest ways to add browser level security to your visitors. Yes some of the headers can be risky, but as long as you understand those risks and spend some time reading up on each header before implementing, most of them just require one off configuration - after which you can forget about them safe in the knowledge that you have made your site that bit more safe. I highly recommend configuring the appropriate HTTP Headers for your website.

After you have reviewed you HTTP security headers, you should check out the HTTP Performance Headers, which work in the exact same way but provide performance enhancements rather than security ones.

This page was originally created on 27-Aug-2015 and last edited on 28-Jun-2022.