Security in Depth; the first layer of addons.mozilla.org20 May 2011
Discussing the security measures of a public facing and popular website is usually taboo. Often owners are unsure they are following best practices, prefer not to draw attention to their site, or hope that they can maintain security through the obscurity of their code. At Mozilla we are fortunate to offer nearly all of the code in the entire company as open source software. addons.mozilla.org is no exception. This means we need to be extra vigilant with the code we write (and a huge thanks to our developers doing code reviews, the security and QA teams testing code, and the community members reporting bugs they find), but it also means I can write posts like this to explain some of the security measures we have implemented and how you can use them to make visitors to your sites safer too.
SSL Encryption: Let's start off easy. Anytime you go to addons.mozilla.org we redirect you to https://addons.mozilla.org. Assuming you make it through the redirect safely you can be reasonably sure you're talking to us at that point. Any data sent between your browser and us is encrypted with industry standard encryption. This seems like a freebie (I know you're thinking, "really? you're talking about SSL?"), but do a quick search and you'll find plenty of financial institutions that fail to take even this most basic precaution on pages where you submit the username and password to your accounts.
For many sites session cookies are one of the most valuable assets behind the actual credentials to log in. AMO protects the session cookie (and most of its cookies) with two very underused options: the Secure and HTTPOnly flags. Secure simply means the cookie is only sent over a secure connection - that means that when you go to addons.mozilla.org without typing the https, your cookies (and therefore your session) aren't sent and won't be compromised if someone is eavesdropping. HTTPOnly means that the cookies are sent with browser traffic to AMO but the cookie is inaccessible to client side scripts. If a malicious script is somehow injected into the page this option will prevent it from stealing the session id. Assuming you don't need access to the cookies and are running SSL these are essentially free additional layers of security for your site.
Every request to AMO returns a pile of interesting (and sometimes bleeding edge) HTTP headers. If you hit the front page, you'll see X-Frame-Options: DENY. In a supporting browser, this will prevent someone from putting the AMO site into an <iframe> (which prevents things like clickjacking). The vast majority of sites can add this header for more free security.
In a couple examples above I say that once you get to AMO on SSL you'll be fine but I conveniently skip all the traffic and redirects up until then. An attempt to keep people safe until they reach that point is the Strict-Transport-Security: max-age=2592000 header. This tells the browser that for the next 30 days, if you type in addons.mozilla.org without https it will automatically send it over SSL before the initial request - no unencrypted traffic at all. Support for this header is not widespread yet, but it's in all the recent versions of Firefox and I expect support for it to expand.
Whew, that is a pile of text and that's just covering the extreme front end. I'm going to cut it off there to keep this from running on for pages but if there is interest I'll write another post about more things AMO does to defend itself and its visitors, and other areas where everyone can consider adding in extra security.
In the mean time, if you want even more best practices the Mozilla Security Team has made a great wiki page for further reading about web security.