This project was merged into Django 1.8, and is now unsupported and unmaintained as a third-party app.
Python Shell
Failed to load latest commit information.
djangosecure Bump version to 1.0.1.post1. Oct 23, 2014
doc Update documentation for default checks Apr 25, 2015
.gitignore Check for bad SECRET_KEY Mar 12, 2013
AUTHORS.rst Update changelog and authors file for SECRET_KEY check; thanks Ram Ra… Apr 15, 2013
CHANGES.rst Bump version to 1.0.1.post1. Oct 23, 2014
LICENSE.txt Corrected copyright notice. Sep 23, 2011 Added docs. May 30, 2011
README.rst Add warning that django-secure is now unsupported and un-maintained. Nov 20, 2015
TODO.rst Added docs. May 30, 2011 Add test coverage measurement in tox. Apr 15, 2013 Update tox.ini; hide tests from old Django test runners. Oct 23, 2014 Add Python 3 trove classifiers. Apr 18, 2013




This project was merged into Django 1.8. It does not provide any additional checks beyond those included in Django 1.8+, so there is no reason to use it with Django 1.8+. Since Django 1.8 is now the lowest supported Django version, this project is now unsupported and un-maintained.

Helping you remember to do the stupid little things to improve your Django site's security.

Inspired by Mozilla's Secure Coding Guidelines, and intended for sites that are entirely or mostly served over SSL (which should include anything with user logins).



Tested with Django 1.4 through trunk, and Python 2.6, 2.7, 3.2, and 3.3. Quite likely works with older versions of both, though; it's not very complicated.


Install from PyPI with pip:

pip install django-secure

or get the in-development version:

pip install django-secure==dev


  • Add "djangosecure" to your INSTALLED_APPS setting.
  • Add "djangosecure.middleware.SecurityMiddleware" to your MIDDLEWARE_CLASSES setting (where depends on your other middlewares, but near the beginning of the list is probably a good choice).
  • Set the SECURE_SSL_REDIRECT setting to True if all non-SSL requests should be permanently redirected to SSL.
  • Set the SECURE_HSTS_SECONDS setting to an integer number of seconds and SECURE_HSTS_INCLUDE_SUBDOMAINS to True, if you want to use HTTP Strict Transport Security.
  • Set the SECURE_FRAME_DENY setting to True, if you want to prevent framing of your pages and protect them from clickjacking.
  • Set the SECURE_CONTENT_TYPE_NOSNIFF setting to True, if you want to prevent the browser from guessing asset content types.
  • Set the SECURE_BROWSER_XSS_FILTER setting to True, if you want to enable the browser's XSS filtering protections.
  • Set SESSION_COOKIE_SECURE and SESSION_COOKIE_HTTPONLY to True if you are using django.contrib.sessions. These settings are not part of django-secure, but they should be used if running a secure site, and the checksecure management command will check their values.
  • Ensure that you're using a long, random and unique SECRET_KEY.
  • Run python checksecure to verify that your settings are properly configured for serving a secure SSL site.


If checksecure gives you the all-clear, all it means is that you're now taking advantage of a small selection of easy security wins. That's great, but it doesn't mean your site or your codebase is secure: only a competent security audit can tell you that.


See the full documentation for more details.