OPINION - Dangerous Web Security Features

This page was originally created on 07-Sep-2015 and last edited on 12-May-2019 .

Introduction

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:

HSTS with a short time initially growing over time, and without includeSubDomains and without adding to the preload list, unless you fully understand what these mean.

includeSubDomains and adding to the preload list, unless you fully understand what these mean. Not to use HPKP at all, except in report-only mode - which will not protect your website against a rogue certificate, but will alert you when there is one (at which point full HPKP may be an option you wish to consider).

Similarly only to use CSP in report-only mode (for now). I do think CSP will become more useful as browser support grows, but it's just not quite there yet in my opinion.

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!

Summary

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 securityheaders.io 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:

HSTS : The web has largely moved to HTTPS since I wrote this post. Three quarters of web traffic is now over HTTPS though it should be noted that this is weighted towards the large sites that make up proportionally more of the traffic, and just over 50% of the top million websites are HTTPS by default at the time of writing. HTTPS is the majority now, and HSTS therefore is less risky than before. However that does not mean it is completely without risk. The Chrome HSTS Removal Request list (which looks like it was stopped being maintained in August 2017), still makes depressing reading for those that turned preload on in error. And just because the public web is encrypted, doesn't mean internal intranets are. In my experience, these lag the public internet, and HTTPS is often still not the norm there. In short, use HSTS, but I'm still against preload unless you know what you are doing or are a high profile target.

: The web has largely moved to HTTPS since I wrote this post. Three quarters of web traffic is now over HTTPS though it should be noted that this is weighted towards the large sites that make up proportionally more of the traffic, and just over 50% of the top million websites are HTTPS by default at the time of writing. HTTPS is the majority now, and HSTS therefore is less risky than before. However that does not mean it is completely without risk. The Chrome HSTS Removal Request list (which looks like it was stopped being maintained in August 2017), still makes depressing reading for those that turned preload on in error. And just because the public web is encrypted, doesn't mean internal intranets are. In my experience, these lag the public internet, and HTTPS is often still not the norm there. In short, use HSTS, but I'm still against preload unless you know what you are doing or are a high profile target. HPKP : Google announced the end of HPKP, precisely for the reasons I gave in this blog post. Even Scott Helme, who was one of it's most ardent supporters anounced he was giving up too. In the end HPKP was too dangerous, and introduced more risks than it solved for most sites. As far as I'm aware preloading pinning in code in the Chrome browser still exists for very high profile sites but, unlike HSTS, there is no easy method to add yourself to this list and you basically need to ask the Chrome developers to do this for you. HPKP was largely replaced by Certificate Transparency, which gives greater visibility to certificates issued by a domain, though unlike HPKP, it does not block so does not offer the same level of protection (or risk!). HPKP was, in hindsite, too dangerous and I'm happy to see it consigned to history.

: Google announced the end of HPKP, precisely for the reasons I gave in this blog post. Even Scott Helme, who was one of it's most ardent supporters anounced he was giving up too. In the end HPKP was too dangerous, and introduced more risks than it solved for most sites. As far as I'm aware preloading pinning in code in the Chrome browser still exists for very high profile sites but, unlike HSTS, there is no easy method to add yourself to this list and you basically need to ask the Chrome developers to do this for you. HPKP was largely replaced by Certificate Transparency, which gives greater visibility to certificates issued by a domain, though unlike HPKP, it does not block so does not offer the same level of protection (or risk!). HPKP was, in hindsite, too dangerous and I'm happy to see it consigned to history. CSP: CSP has really taken off in the last 3 years, browser bugs have been fixed, and I would now recommend it for sites as the strongest protection against XSS. It should of course be used as a backup to protections in your code rather than a replacement, but it's a great added protection for defence in depth. Saying that it is complicated to set up right. It has been shown that between 94.68% and 99.34% of CSP policies are effectively useless! The problem is setting up a secure, and useful CSP takes considerable time, effort and a great deal of understanding of your website, and often a lot of code refactoring. That's not a reason not to do it of course, but it does explain why it's usage is not where it should be. Perhaps "dangerous" was a little strong for CSP (though I stand by that assessment for HPKP and for preloading HSTS without understanding it), but it's certainly got the potential to break sites. And when you add 3rd party assets that potential increases hugely. CSP reporting is next to useless in my opinion because of the noise and variety of browsers. I have it implemented on this site (and the sites I code for work) and I monitor the volume of CSP alerts for large increases for some reason, but there's often some obscure browser that CSP has broken that goes under the radar long enough to not be noticed through those. One thing that is really useful is to use upgrade-insecure-requests to allow ease of transition to HTTPS if you've not moved yet. Browser support is good, and yes there are risks of moving to HTTPS, but you just need to get on and do this because the web is moving that way! In summary, CSP is good, and you should use it, but takes a lot of effort to implement it correctly (though you can use some features like upgrade-insecure-requests without having to use a full blown CSP).

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 07-Sep-2015 and last edited on 12-May-2019 .