site logoTune The Web
I've written a book! - click here to view or buy "HTTP/2 in Action" from Manning. Use code 39pollard to get 39% off!

OPINION - Dangerous Web Security Features

This page was originally created on and last edited on .


Note this post was written in 2015. Some of the security landscape has changed since then. Read this in mind of that, and I give an update at the bottom of this post. I still think the post is useful which is why I am leaving it up, but I do advise when reading blog posts on the web to check the publication date! My publication dates are at the top and bottom of the articles.

There has been a welcome growth in a number of security options available to web site owners to protect their websites and their users. Some of these have been around for a while and some have been talked about for a while but are only starting to be supported by web browsers. Innovations like Strict-Transport-Security (aka HSTS), Public-Key-Pins (aka HPKP) and Content Security Policy (aka CSP) are being supported by more and more browsers and are now available as security options to those website owners who wish to implement them.

When Google announced they were Rolling out Public Key Pinning with HPKP Reporting there was a bit of excitement amongst the web security community on the Internet. Scott Helme also has done some fantastic work in this field, from his blog to creating a HPKP and CSP toolset, and of course the report-uri tool itself. The SSLLabs scanning tool is now showing whether sites are preloaded for HSTS, which again will spark interest in that.

So support is up, implementation is easier thanks to the work of others, and everyone should rush in, right?

Well, I want to advise caution, and think most website owners should not implement some of these, due to the risks they are putting their website under. I'm not sure that some of these options are for the mainstream, or ever should be.

So you don't think web security's important then?

That's incorrect, I absolutely do think web security is massively important. So much so I set up this site, in part to try to promote web security and improve websites! However what I don't believe is that you should set up security above all else. Implementing security, like most things in life is a balance, and you need to weigh up the risks versus the reward. My issue with implementing some of these features is that the risk they are trying to mitigate, are often much smaller than the risk they are introducing.

Why are these features so "dangerous" then?

I've a few concerns. One of the main issues with some of these feature is that they are not easily reversible if you make a mistake with them. A lot of these have long life, or even permanent status once you switch them on, and that doesn't sit comfortably with me. Yes you can argue that whoever is implementing them has a duty to make sure they are implemented properly and I don't dispute that - but people do make mistakes, and when such a mistake can basically permanently take down a website, then that should be a big cause for concern.

Even if policies are implemented properly - things do change! Websites evolve, certificates need replacing, and people who may have set up these policies will be replaced by people who don't understand them. So while you may implement all of these features, and make one of the most secure websites in the world, and pat yourself on the back for that, you may well have left a ticking time bomb for the person coming after you. When a change needs to happen that breaks these policies, all that back patting earlier may not seem worth it after all!

The other issue is that browser support is just not there yet. There have been some great strides on these recently, but there are still some missing key features from most browsers, and until they are there, there are a lot of unknowns out there and some of the bugs make some of these options downright dangerous in my opinion.

Let's get into specifics

OK let's talk about each of these options and what specifically I don't like about them:

Most sites should only use very basic versions of these options

In my opinion, some of these options are just not well enough understood for people to seriously consider implementing them on commercial sites, and that's why I've written this anti-rallying cry, to say "Stop and proceed with caution!"

It's fantastic to give a website owner this level of control, and I am not against any of these options, if people really need them. I'm just against people implementing them without fully understanding them as potentially they are very dangerous.

Yes most of the RFCs for them, and the guides various people have put on the internet about how to set the up (my own included), call out the risks but in my opinion not strongly enough.

I also think some of these policies are simply not necessary for the vast majority of websites. For the high value targets like Google, Facebook, Internet Banking sites absolutely - they are great options for them. And you would imagine the internet giants at least would have the experience and understanding necessary to implement them correctly and handle the ongoing support they require, but for most of the rest of us that's not the case. HPKP in particular requires quite a detailed attack (a certificate issued by a CA in error, or by a compromised CA, and a DNS poisoning attack), and I've really got to ask if that is more likely than a website owner accidentally DoS-ing their own site with an incorrect implementation?

My recommendations

My recommendations would be for most sites to use:

These will add a good level of security, and visibility if there are any security attacks on the site, but without the risks of blocking your sites. They are not the most secure settings possible, and some sites will require more secure settings and will benefit from the full secure options, but those represent a very small minority in my opinion.

And if you log reports - then you need to set up some sort of process to look at them regularly. Otherwise there's really no point!


I think web security is extremely important, and it's importance will only grow in this always-on internet connected world. So with that in mind, any additional tools in a website owner's security arsenal are usually to be welcomed. However security is a complicated issue, and that means some of the answers to our security problems are complicated in themselves. It's rare to find security solutions, which are easy to implement, with no downsides. You need to decide if those downsides are worth the upside of the extra protection implementing that security feature gives you. I have real worries whether these policies do have this balance (particularly in their strictest settings).

I do recognise the in built protections some of these settings have, and it's not like these fears have not been considered. I think the report-only options are a fantastic idea - and as mentioned above, perhaps using only the report-only options may be sufficient protection in themselves as a warning system, if monitored properly. I do wish the browsers had implemented the report-only options first (HPKP is available for most browsers but the report only option has only just become supported in one browser - Chrome), and there are clearly some bugs to fix here on the CSP side when you have both report-only and blocking policies at the same time, but on the whole the concept of report-only options are fantastic. However they are very, very, very noisy for CSP (which severely dents their usefulness), but so far I've had no such issue with HPKP report-only.

Additionally the fact that incorrect HPKP policies are ignored, and two distinct pins are needed for a policy to be valid and be accepted, does make it very hard for someone to screw their site up too badly. But the problem is, not in the initial set up (which these protections help ensure doesn't cause problems), but in the ongoing maintenance. Certificates need changing frequently (usually annually) so saying only certain certificates can be used on a site, doesn't really fit well with that operating model. I mentioned above, and still believe that some of these are time bombs, that even if you know how to set them up, could easily trip up the next person who looks after your website if you ever move on. Maybe, as they become more popular, they will become a standard part of every sys admins knowledge, but in my experience a lot of security options are, unfortunately, far too niche specialities.

There are other HTTP Security Headers, which have very little downsides and should be used, and I do like Scott Helme's webtool for quickly analysing your website for these. I also think Certificate Transparency might be another one of those rare security options which don't have downsides, so am a big fan of that - though I accept that it's more a way of warning you of a security problem rather than blocking them. So in some ways it's similar to some of the report-only versions of above security options - and maybe that's sufficient for most sites? And again, browser and CA support is just not there yet for Certificate Transparency, but hopefully will be soon.

Ultimately, it's up to site owners to implement site settings correctly of course, and more choice and options on adding security is usually a good thing in my opinion. So perhaps my fears here are overblown and I should stop being so negative, but I think no harm to have one blog post dedicated to calling out these risks.

Update 21st April 2019

This post was recently on Hackernews and generated some discussion, so I thought I'd better clarify a few things. First up I want to say that the post is 3 and a half years old as I write this and a lot has changed since then. I think my concerns were valid back in September 2015; some of it has become less valid since, and some has proven to be entirely correct. It's probably time to do an updated posted, but until I get time to do that, here's a smaller update of where my feelings are now:

So, all in all, there's one security option (HSTS) I do recommend now (though still without preload), one (HPKP) I feel totally vindicated on, and one (CSP) thats somewhere in the middle - use it, but with caution that it's difficult to set up correctly. Which isn't that far away from the recommendations of my original post to be honest. CSP is probably the one that changed the most as originally I only recommended it in report-only mode but I would go further than that now - providing you have the skillset and understanding to implement it properly.

I've also had a few people commenting that this post is more dangerous than the security options I'm talking about here. I strongly refute that and suggest those people have not read this post fully. I do recommend most of these security options, but only after you understand them properly (at least in their strictest settings). I think that is much better than many random blog posts recommending switching them on, often to chase a grade on a security scanning tool, without fully explaining them - which is something I see far too often! As I said at the beginning, my issue with implementing some of these features is that the risk they are trying to mitigate, are often much smaller than the risk they are introducing. Those who practice "absolute security", without a view of the risks they are mitigating against (and introducing!) often cause problems in my opinion and then that just make people relucant to implement security options in the future.

Do you agree? Disagree? Let me know below your thoughts below.

This page was originally created on and last edited on .

How useful was this page?
Loading interactions…