Security through HTTP response headers

Security headers in an HTTP response

There are many things to consider when securing a web application but a definite "quick win" is to start taking advantage of the security HTTP response headers that are supported in most modern browser. It doesn't matter which development platform you use to build your application, these headers will make a notable difference for the security of your website anyway!

The screenshot shows what the security headers look like. The security headers are included in the web server's response to a browser — instructing the browser to enable (or disable) certain security features. They're invisible to the user, but you can have look at them with tools such as Fiddler or the developer tools that are built into the major browsers. In IE or Chrome press F12, in Opera (Ctrl+Shift+i), in Firefox (Ctrl+Shift+k), for Safari have a look here to enable the developer tools.

A great thing about these response headers is that they're very easy to get started with. In many cases you might not even have to change a single line of code in your application as you can set the headers either through your application's configuration, or they can likely be set by whatever web server you use.

If you're building ASP.NET applications I would like to point you to NWebsec, an ASP.NET security library that lets you easily configure these headers for your application. Go and have a look at the documentation, it explains how you can configure the headers through web.config. Don't worry, if you're the MVC kind of person you can use filter attributes instead. You'll find the library on NuGet so you'll be up and running in a matter of minutes! Disclaimer: I built it, so I think it's pretty cool.

A quick note: Last year, I gave a lightning talk at the ROOTs conference about the role browsers play for your online security. There I also discussed security headers. Slides and video are online if you want to check them out: "The browser - your best friend and worst enemy" (slides / video).

Now let's have a look at the headers and how they can improve the security of your website.

IE auto-upgrades, plugins next?

Last week the IE team announced that they'll soon start to automatically upgrade IE across Windows 7, XP, and Vista through Windows Update. A follow up from Microsoft's IT pro team details that IE 6 and IE 7 will be upgraded to IE 8 on Windows XP, while Vista and Windows 7 users will get IE 9. With Microsoft joining the herd of auto-upgraders the final pieces of the puzzle start to fall into place, now "everybody" does it. Other major browser manufacturers (Opera, Chrome, and Firefox) have been auto-upgrading their installations for some time already. Apple's Safari now stands out in the crowd and it will be interesting to see whether they'll stick to their current update regime.

For Microsoft, this is yet another important step to kill of IE 6 which still has a considerable user base. Up til now they have been running campaigns urging users to upgrade their browsers. They actually have a website dedicated to kill of the browser, www.ie6countdown.com (I have to point out that Norway is leading the pack, with only 0.2% IE 6 users). Hopefully the automatic upgrades will have a notable impact on the remaining IE 6 installations.

In two earlier posts (one and two) I've advocated silent auto-upgrades as an important strategy to keep Internet users safe by providing them with timely security patches. Recently I came across an interesting study on the effectiveness of different Web browsers update mechanisms. It's definitely worth a read. (*Surprise*, it aligns just fine with my views so I can safely link to it).