Let's Talk
Because it's secure by default.
No, we don’t use Django just because it’s cool. We use it because modern frameworks, like Django, Pyramid or Ruby on Rails provide extra security by default.
Many security issues are related to a reluctance to use a robust framework and instead constantly roll your own solutions, as PHP encourages. We try to avoid that. Django – and actually any modern framework like Ruby on Rails or Laravel – gives security features without having the developer worrying about it.
The first one is XSS protection. The Django template language transparently HTML-escapes any variable before outputting it without any programming intervention. The escaping must be explicitly turned off if not needed, as apposed to other template languages like PHP where an escaping function must be manually called whenever outputting a variable. A common security vulnerable in PHP is to forget the call to htmlspecialchars, which opens up an XSS hole.
Another one is SQL injection. Thanks to its ORM, Django escapes values sent to the database by default protecting from SQL injection. To be honest, SQL injections shouldn’t exist in PHP which has PDO and parameterized queries. SQL injections in PHP are mainly due to bad practices like using the deprecated mysql_query. The problem is that the wrong way to do it is much cleaner to write than the right way. It's easier to write
1 | mysql_query('SELECT * FROM foo WHERE x = '. $x .' AND y = '. $y);
|
Than it is to write
1 2 3 | $stmt = $dbh->prepare('SELECT * FROM foo WHERE x = ? AND y = ?');
$stmt->bindParam(1, $x);
$stmt->bindParam(2, $y);
|
Since Django has an ORM, it's rare to even write raw SQL, but when you do, a clean interface is provided to do it the write way, with a parametrized query:
1 | cursor.execute('SELECT * FROM foo WHERE x = %s AND y = %s', [x, y])
|
Django also has secure defaults in other areas
- CSRF protection is required by default (https://docs.djangoproject.com/en/1.8/ref/csrf/)
- Click-Jacking prevention is enabled by default (https://docs.djangoproject.com/en/1.8/ref/clickjacking/)
- Passwords are hashed with PBKDF2, a slow password hash function recommended by NIST
- Session cookies are httponly by default. When HTTPS is used, there's a setting to set the secure flag on session cookies.
Finally, most of our developers have contributed to Django itself, and have an understanding of Django’s code. Because of this, they can easily spot and report a security issue. Whenever a vulnerability in Django is discovered, a new version is immediately released.