Django Security Checklist: From Settings to Production
.png)
Django's defaults are genuinely good — better than most frameworks out of the box. But "good defaults" doesn't mean "secure by accident." Most Django security incidents I've seen trace back to a handful of settings that were never revisited after local development. Here's the checklist I actually run before any Django project goes live.
Run the built-in deployment check first
Before touching anything manually, let Django tell you what it already knows is wrong:
This flags common issues like DEBUG=True, missing HSTS settings, and an insecure SECRET_KEY — treat every warning as something to actually fix, not just acknowledge.
The production settings block
A reasonable baseline for settings.py in production:
ALLOWED_HOSTS= ['yourdomain.com','www.yourdomain.com']
SECURE_SSL_REDIRECT= True
SECURE_HSTS_SECONDS= 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS= True
SECURE_HSTS_PRELOAD= True
SESSION_COOKIE_SECURE= True
CSRF_COOKIE_SECURE= True
SESSION_COOKIE_HTTPONLY= True
X_FRAME_OPTIONS= 'DENY'
SECURE_CONTENT_TYPE_NOSNIFF= True
SESSION_COOKIE_SECURE and CSRF_COOKIE_SECURE ensure these cookies are only ever sent over HTTPS — without them, a session cookie could leak over an accidental plain HTTP connection.
SECRET_KEY doesn't belong in your codebase
SECRET_KEY signs sessions, password reset tokens, and CSRF tokens — if it leaks, all of that can be forged. Pull it from the environment instead of hardcoding it:
SECRET_KEY= os.environ['DJANGO_SECRET_KEY']
Using os.environ[...] instead of os.environ.get(...) is deliberate — it raises a clear error at startup if the variable is missing, rather than silently falling back to an insecure default.
Stay inside the ORM for SQL safety
Django's ORM parameterizes queries automatically. The risk reappears the moment raw SQL is built with string formatting:
User.objects.raw(f"SELECT * FROM users WHERE email = '{email}'")
# ✓ Safe — parameterized
User.objects.raw("SELECT * FROM users WHERE email = %s", [email])
# ✓ Better — use the ORM directly
User.objects.filter(email=email)
A pre-launch checklist worth keeping
manage.py check --deploy returns no warningsDEBUG is False and confirmed by actually visiting a broken URL in the deployed environmentALLOWED_HOSTS is an explicit list, never a wildcardWant a real security review of your Django application before it goes live, or after it's already been running for a while? This is part of what I cover in DevOps services engagements alongside infrastructure hardening.