• Best Basic Security Practices (Especially with Django)

    by  • 17 July 2012 • Security

    Or: Locking Your Doors

    This goes along with a talk I gave at Django-NYC in July 2012, but is meant to stand on its own. It is the first in a series of posts, because I realized it was too big for one.

    Security is proportional. Most apps don’t need two-factor auth—some certainly do—but there is a set of common attacks, easily mitigated, that basically any transactional web application is vulnerable to.

    Covering these basics is like locking your car doors. For most cars, a thief is just going to try the handle and then move on. If you’re driving a Ferrari or have a bag of cash sitting in the back seat—if you’re a bank or a high-profile target—you’re going to need to be more proactive.

    At Mozilla, we’ve rolled a lot of this into Playdoh, our Django application template, and funfactory, a Django app that actually holds a lot of the code.

    These best-practices are locking your doors. If your site is a high-profile target or handles financial data, you’ll need to go beyond this.

    OWASP

    Before I go on, a fantastic resource for web app developers is OWASP. The group maintains a ton of great info about common and emerging attacks against web apps, how to mitigate attack vectors, and more. They’re worth bookmarking, following, even joining.

    The Series

    This is the first post in a series. The series will cover what I covered in the talk, but it’s too big for a single blog post, so I’m breaking it up into a series of posts that will go up this week and next. The basic structure is:

    Over the next week or so, I’ll fill in that outline with links to the individual posts, so if you want to bookmark this one, it’s not a bad place to start. Or look at the security tag on this blog.

    • http://psssoftware.net/ phpguy

      You would be surprised how many people dont lock their car doors. If it weren’t so sad Id call it amazing :-)

    • http://jamessocol.com/ James

      And we all have passwords stored in plaintext on someone’s server, somewhere. :(

    • http://www.matthewfedak.co.uk php guy matthew fedak

      The browser is the interesting one, with so many devs declining to support older browsers now and rightfully we still need to remember to test for atleast security purposes in older browsers. Just cause a site don’t support IE6 doesn’t meen its not vulnerable to it.

    • http://jamessocol.com/ James

      Old IE in particular, but there are also attacks that only work against, say, modern Opera. (Look up -o-link and -o-link-source.) Or tricks with conditional comments. (Thanks IE.) But if your bases are covered, with the exception of browsers that don’t support X-Frame-Options, you should generally be OK. But yeah, still worth testing if you have time or traffic from those users.

    • http://www.premium-sites.net Paul G

      Signed up for future posts in the series, thanks James

    • http://about.me/justizin Justin Alan Ryan

      Great stuff, looking forward to the upcoming additional posts!

    • antrek

      James, what’s your view on client-side encryption in web apps?

    • Pingback: Intermission « Coffee on the Keyboard()