django-secure 1.0.2

Utilities and a 'linter' to help you make your Django site more secure.

Warning

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).

Quickstart

Dependencies

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.

Installation

Install from PyPI with pip:

pip install django-secure

or get the in-development version:

pip install django-secure==dev

Usage

• 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 manage.py checksecure to verify that your settings are properly configured for serving a secure SSL site.

Warning

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.

Documentation

See the full documentation for more details.

CHANGES

1.0.2 (2020.03.31)

• This project was merged into Django 1.8 and its features are now part of core Django. Thus it is unmaintained and you should not use it.

1.0.1 (2014.10.23)

• Hide django-secure tests from pre-1.6 Django test runners, to avoid breaking project tests.

1.0 (2013.04.17)

• BACKWARDS INCOMPATIBLE: Dropped tested support for Python 2.5, Django 1.2, and Django 1.3.

• Added support and testing for Python 3 (though all non-test code worked fine under Python 3 previously.)

0.1.3 (2013.04.17)

• Added check for SECRET_KEY. Thanks Ram Rachum.

0.1.2 (2012.04.13)

• Added the SECURE_HSTS_INCLUDE_SUBDOMAINS setting. Thanks Paul McMillan for the report and Donald Stufft for the patch. Fixes #13.

• Added the X-XSS-Protection: 1; mode=block header. Thanks Johannas Heller.

0.1.1 (2011.11.23)

• Added the X-Content-Type-Options: nosniff header. Thanks Johannas Heller.

• SECURE_PROXY_SSL_HEADER setting now patches request.is_secure() so it respects proxied SSL, to avoid redirects to http that should be to https.

0.1.0 (2011.05.29)

• Initial release.

TODO