Django 1.8 Security Best Practices

Ronald Reagan once said, “Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders.”

The web is a very scary place. Viruses spread across the web at a very fast speed, worms replicate themselves at an unprecedented pace, and it’s not uncommon to hear about hackers bringing down a system. As a software engineer, I have a duty to do my best to protect the systems we develop at Tivix. While I was reading Two Scoops of Django by Daniel Roy Greenfeld and Audrey Roy Greenfeld, I picked up a few tricks that I consider not only important, but a must-have under your pillow.

  • Know Django’s Security Features
    Django 1.8’s security features include:
    • Cross-site scripting (XXS) protection.
    • Cross-site request forgery (CSRF) protection.
    • SQL injection protection.
    • Clickjacking protection
    • Support for TLS/ HTTPS/HSTS, including secure cookies.
    • Secure password storage, using the PBKDF2 algorithm with a SHA256 hash by default.
    • Automatic HTML escaping.
    • An expat parser hardened against XML bomb attacks.
    • Hardened JSON, YAML, and XML serialization/ deserialization tools. 
  • Turn off DEBUG Mode in Production
    Your production environment should NEVER be running with DEBUG turned on. DEBUG mode displays detailed error pages. If an exception is raised, Django will display a detailed traceback which includes a significant amount of metadata about your environment.
  • Keep your secret keys secret
    By definition, secret means “not known or seen, or not meant to be known or seen by others.” Otherwise, you risk everything from remote code execution to password hacking. A good practice is to store secret keys on environment variables or non-executable files in the format of JSON, Config, YAML, or even XAML.
  • HTTPS (Hypertext Transport Protocol Secure)  Everywhere
    This is a secure protocol used to send and receive encrypted data with the help of SSL (Secure Socket Layer). Not using HTTPS means that data sent between a site and end users

These are just a few examples of how to keep our applications secure. Consider this blog post as a starting point. As I mentioned before, Django comes with good security features, but it’s still a daunting task to dive into such an important topic. Django Security Documentation is always a good place to start.

Django 1.8 Security Best Practices

Leave a Reply

Your email address will not be published. Required fields are marked *