The Cost Of Security Headers

I see a lot of blog posts about the positives that HTTP security headers have. I see few that explain the negatives and warn the readers to beware. Security headers come with an added cost that can be extremely high. Before deploying a security header you MUST take the time to fully understand it.

What's wrong with security headers?

Complexity. Some security headers are extremely complex operationally, and a mistake can break your site for all of your recent users. They are also complex to understand and they aren't getting any simpler. This isn't an inherent problem with the headers, just how people are using them. Let's look at a few examples and talk about what can go wrong.

HTTP Public Key Pinning

HTTP Public Key Pinning (HPKP) has a very important role in web application security. It is a way to enforce that a browser should remember a server's cryptographic identity for some duration of time. Even Ryan Sleevi, one of the names on the RFC isn't super pleased with how it turned out.

HPKP fills a very important niche but it is absolutely not for everyone. If you operate a website then this quote in the security considerations of the RFC should alarm you.

If the operator had pinned only the key of the host's end-entity certificate, the operator would not be able to serve their web site or application in a way that UAs would trust for the duration of their pin's max-age.

HPKP adds a burden to the already difficult task of key management. If you are not prepared for this you will eventually make a mistake and brick your site.

HTTP Strict Transport Security

HSTS is similar to HPKP except much simpler. It is an HTTP header that when sent HTTPS, indicates a time-frame that browsers should ONLY connect to that hostname using HTTPS and never HTTP. It can also indicate that all subdomains of that hostname should also be HTTPS. This header actually is widely deployed and has even been adopted widely in a stricter form, the HSTS preload list, but it provides engineers with plenty of foot to shoot.

The interesting thing about HSTS and the preload list is that we can actually see which sites ended up running in to issues by observing which sites are removed from the preload list. Being removed from the preload list is actually fairly common. Some sites are submitted to the preload list without their knowledge, which explains why they want to be removed

But many web sites just have issues operationally and realize after submitting to the preload list that they can't actually support HTTPS across all of their subdomains. Even uber made this mistake. If uber wasn't prepared maybe you won't be prepared either.

The Negatives.

It's also possible to make your site less secure with HTTP headers. As an example, Access Control Allow Origin with Access Control Allow Credentials can be misconfigured to allow any origin to steal session information. I wrote a blog post about this in the past.

There's also lots of bad information out there. Here's an awful answer on StackOverflow that was highly upvoted.


Security headers are complicated. All security headers have an operational costs and there's lots of advice out there that might not what's best for you.

HTTP headers should be fully researched and understood before deploying them. Don't listen to blog posts and external pressure that make security headers sound like butterflys and rainbows. All of the headers have good configurations and bad configurations. Please consider this.

ejj, March 2016