Friday Links 0.0.6 - Security Headers

This is based on an email I send my .NET team at work

Happy Friday,

Today I want to talk about some of the new HTTP headers you can set to help protect your users from various online attacks. is a really interesting site that scans a domain and reports on the HTTP headers it sets related to security. For example, here’s the scan for

For each of the headers it finds, it includes links to detailed information about what the header does and how it protects your users. I think anytime we deploy a site for a client, we should strongly consider spending a little bit of time setting up the relevant headers. Most of the time we could accomplish that through a little ASP.NET HTTP Module that slipped the right headers into the Response object.

But I want to talk about some of these that I think are interesting.


The X-Frame-Options header tells the browser how your site can be iframed. In a lot of cases, you would prefer it never be iframed as this can allow attackers to perform click-jacking attacks against your users. You can also, if needed, specify that your site can only be iframed into sites you trust.


The Content-Security-Policy header tells the browser what its allowed to do with embedded or referenced content. This can be used to protect against cross site scripting attacks (XSS) where an attacker is able to embed their own malicious content into your site (perhaps through a comments feature for example).

There’s a ton of policies you can tweak with this header. You can specify from which domains the browser is allowed to load scripts, images, styles and other media. You can restrict form action attributes. You can even give it a URL where the browser will report violations so you can further refine your policy.

These options make it so that even if your site is vulnerable to XSS, there is a limit to the types of things the attacker can accomplish with the vulnerability


The Strict-Transport-Security header tells your browser to never, ever, under any circumstances, connect to your site using HTTP : It must always use HTTPS. The concept is also known as HTTP Strict Transport Security (HSTS).

This protects against an attack by a Man in the Middle (MiTM) where the attacker sits between your user and your site, and proxies the data. The issue is that by default browsers initialize an HTTP connection. When you just type into your browsers URL bar, it defaults to an HTTP connection. But since the bank wants you to be secure, it issues a 301 Redirect Permanently header and tells you to come back using HTTPS. The MiTM, though, can strip that header out on the way back to your browser, while maintaining the secure connection with the server:

You   <==== HTTP ====>   MiTM   <==== HTTPS ====>  Bank

Both you and the bank are none the wiser.

Without this header, the only defense is the vigilance of the user: they would need to notice that there is no green lock on their URL bar. Most non-technical users are not inclined to be this attentive.

The Strict-Transport-Security header works in conjunction with that initial 301 redirect and tells the browser to never again connect using HTTP.

Now there is still a hole in this: if the MiTM is in place during that first initial connection, they can easily strip out the HSTS header along with the redirect. However, the use of the Strict-Transport- Security header helps greatly reduce the exposure to the MiTM: the only way the attack can work is to be in place during the first connection.

To combat that attack, there is another extension called HSTS preloading. This is a browser feature where the software ships with a pre-existing list of sites to which it should never connect using HTTP. You can submit your site to the preload list using and if accepted, the next versions of all the major browsers will add your site to their list.

For example, here’s the list for Chrome:

Lets do our best to keep our clients and our users secure.