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).
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 manage.py 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.
- Design Goals
- The checksecure management command
- Settings Reference