Security hardening

Django's security defaults are better than most frameworks, but defaults are not enough for production. This hub covers the authentication patterns, header policies, secret management, and operational security practices that protect real applications.

Security audit checklist with lock and authentication flow diagrams

Django ships with CSRF protection, XSS prevention through template auto-escaping, SQL injection prevention through the ORM, clickjacking protection via middleware, and secure session handling. These defaults are genuinely good and protect applications even when individual developers are not actively thinking about security on every line of code. But defaults only cover the framework layer. The application layer, the deployment layer, and the operational practices around your Django project are where most real vulnerabilities live. In this hub I collect the security guides, hardening checklists, and authentication patterns that address the full surface.

The guides below cover authentication architecture, the pre-deployment security checklist, and the header policies that harden your application at the HTTP layer. If you are looking for deployment-specific security concerns like secret management and environment isolation, see the deployment hub. For the framework-level security model, the framework overview maps where security middleware fits in the request lifecycle.

Security layers diagram showing Django middleware, application, and infrastructure security surfaces
Security surfaces in a Django application: framework defaults, application logic, deployment configuration, and infrastructure.

Security guides

Django security checklist The pre-deployment security review covering settings, headers, CSRF, session configuration, and the operational checks that should pass before traffic arrives. Authentication patterns Custom user models, session management, permission architecture, group-based access, and the authentication flows that production applications need. Settings for production Secret management, environment isolation, and the settings configuration that prevents security-critical misconfigurations in deployed environments.

Core security concerns

CSRF protection in Django works through a combination of middleware and template tags. The middleware sets a token in a cookie, and the template tag includes it in forms. The mismatch between cookie and form token triggers a 403 on any cross-site request that does not carry the correct token. This is automatic for standard form submissions but requires explicit handling for AJAX requests. The most common CSRF mistakes are exempting views that should be protected and failing to include the token in JavaScript-driven form submissions.

Authentication in Django goes beyond login and logout. The permission system supports object-level permissions, group-based access control, and custom authentication backends. For most applications, the default authentication with a custom user model is sufficient. The custom user model should be created at the start of the project, before the first migration, because changing the user model after migrations exist is one of the most painful operations in Django development.

HTTP security headers are your defense at the network layer. Content-Security-Policy controls what resources can load on your pages. Strict-Transport-Security ensures HTTPS. X-Content-Type-Options prevents MIME sniffing. Referrer-Policy controls what information leaks to other sites. Django provides middleware for some of these, but CSP usually requires additional configuration or a library like django-csp. The security checklist covers every header you should verify.

Secret management is the operational security concern that sits between your application and your infrastructure. Django's SECRET_KEY, database passwords, API keys, and email credentials should never appear in version control. Environment variables, secrets managers, and encrypted configuration files are the standard approaches. The key principle is that a clone of your repository should not contain enough information to access any production resource.

HTTP response headers showing security configuration including CSP, HSTS, and X-Content-Type-Options
Security headers on a hardened Django response: CSP, HSTS, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.
⚠

Common security mistakes

  1. Running production with DEBUG=True, exposing tracebacks, settings, and database queries to attackers.
  2. Not creating a custom user model before the first migration, making it painful to extend later.
  3. Exempting views from CSRF protection without understanding the implications for cross-site request safety.
  4. Storing secrets in version control instead of environment variables or a secrets manager.
  5. Missing Content-Security-Policy headers, which allows attackers to inject scripts through any XSS vulnerability.
  6. Using weak session configuration that allows session fixation or session hijacking.

What to read next

Start with the security checklist if you are preparing a deployment. For authentication architecture, the authentication patterns guide covers user models, permissions, and session management. For secret management and settings isolation, the settings guide in the deployment hub covers the exact patterns. If you are testing security-critical paths, the testing hub has relevant strategies.