Django ships with sane defaults, but "secure by default" only holds up if you don't quietly undo the protections while shipping features under deadline pressure. This is the checklist we run through on every Django project before it touches production traffic.
1. Lock down your settings
The most common mistake is leaving development settings in production.
# settings/production.py
DEBUG = False
ALLOWED_HOSTS = ["zalvantic.com", "www.zalvantic.com"]
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_CONTENT_TYPE_NOSNIFF = True
DEBUG = True in production is still, in 2026, one of the most common causes of leaked stack traces and environment variables. Treat it as a deploy-blocking check, not a code review nitpick.
2. Never trust SECRET_KEY in version control
Pull it from the environment, always:
import os
SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]
If it's ever been committed to git history, rotate it removing the file later doesn't remove it from history.
3. Query safely, every time
Django's ORM protects you from SQL injection if you use it correctly. Raw queries with string formatting reopen the exact vulnerability the ORM exists to prevent:
# Dangerous — vulnerable to SQL injection
User.objects.raw(f"SELECT * FROM auth_user WHERE username = '{username}'")
# Safe — parameterized
User.objects.raw("SELECT * FROM auth_user WHERE username = %s", [username])
Prefer the ORM's query API entirely where possible; reach for .raw() only when there's no other option.
4. Keep dependencies current
A framework is only as secure as the dependency tree underneath it.
Run pip-audit or safety in CI on every pull request, not just before releases:
pip install pip-audit
pip-audit -r requirements.txt
Production hardening checklist
-
DEBUG = Falseenforced via environment-specific settings -
SECRET_KEYand all credentials loaded from environment variables - HTTPS enforced with HSTS
- Dependency scanning wired into CI
- Rate limiting on authentication endpoints
- Content Security Policy headers configured
Closing thoughts
None of this is exotic it's a checklist, and that's exactly the point. Security incidents in Django apps are rarely caused by a zero-day in the framework itself; they're caused by one of these basics being skipped under deadline pressure.
Looking for a security review before your next release? Talk to our team.
