Credential Stuffing in Django (Python)

Credential stuffing is a volume-based attack where attackers use automated scripts to submit previously breached username and password pairs against a login endpoint. In Django, the default authentication view (django.contrib.auth.views.LoginView) provides a predictable URL and JSON-friendly responses when configured with an API-oriented frontend. When session cookies are not sufficiently protected and rate limiting is absent or misconfigured, Python-based automation can iterate through thousands of credential pairs with minimal friction.

The Django authentication stack uses authenticate() and login() from django.contrib.auth. If account lockout is not implemented, each request returns a distinct response that can help an attacker infer whether a username exists. Python scripts leveraging libraries like requests and aiohttp can rotate IPs and use session pooling to bypass simple IP-based throttling. Without per-account rate limiting in Django middleware or at the proxy layer, a credential stuffing campaign can run unchecked against user accounts that reuse passwords.

Common misconfigurations that amplify risk include allowing unlimited POST requests to the login URL, failing to enforce HTTPS, and exposing detailed validation errors that leak account status. When Django’s LOGIN_URL is reachable without CSRF checks for API-style clients, Python tools can easily bypass browser-centric protections. Attackers often source credential lists from public breaches and feed them into Python-driven pipelines, using the language’s rich ecosystem to parallelize attempts and parse responses for successful authentication indicators.

Defending against credential stuffing in Django involves tightening authentication flow, introducing per-account rate limiting, and hardening responses using Python code. Below are concrete, idiomatic examples you can apply in your Django project.

1. Add per-account rate limiting in middleware

Create a middleware that tracks failed attempts per username or IP+username and temporarily blocks excessive requests. This Python logic integrates cleanly with Django’s request/response cycle.

import time
from django.http import HttpResponseForbidden
from django.contrib.auth import get_user_model

User = get_user_model()

class CredentialStuffingProtectionMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
        # Simple in-memory store; use Redis in production
        self.failed_attempts = {}

    def __call__(self, request):
        if request.path == '/login/' and request.method == 'POST':
            username = request.POST.get('username', '')
            key = f'login:{username}'
            now = time.time()
            attempts = self.failed_attempts.get(key, [])
            # Remove attempts older than 15 minutes
            recent = [t for t in attempts if now - t < 900]
            if len(recent) >= 10:  # 10 failed attempts per 15 minutes
                return HttpResponseForbidden('Too many attempts. Try again later.')
            self.failed_attempts[key] = recent

        response = self.get_response(request)
        # Optionally clean up old entries periodically
        return response

2. Use Django-ratelimit for decorator-based control

The django-ratelimit package lets you annotate views with per-user or per-IP limits. This approach is explicit and testable in Python.

from ratelimit.decorators import ratelimit
from django.contrib.auth import authenticate, login
from django.shortcuts import render, redirect

@ratelimit(key='ip', rate='5/m', block=True)
@ratelimit(key='user', rate='5/m', block=True)
def login_view(request):
    if request.method == 'POST':
        username = request.POST.get('username')
        password = request.POST.get('password')
        user = authenticate(request, username=username, password=password)
        if user is not None:
            login(request, user)
            return redirect('home')
        return render(request, 'login.html', {'error': 'Invalid credentials'})
    return render(request, 'login.html')

3. Standardize error responses to avoid user enumeration

Ensure that failed logins return a generic message and consistent HTTP status code so automated scanners cannot distinguish between valid and invalid usernames.

from django.shortcuts import render
from django.contrib.auth import authenticate, login

def login_view(request):
    if request.method == 'POST':
        username = request.POST.get('username')
        password = request.POST.get('password')
        user = authenticate(request, username=username, password=password)
        if user is not None:
            login(request, user)
            return redirect('home')
        # Always render same template with same status
        return render(request, 'login.html', {'error': 'Invalid credentials'})
    return render(request, 'login.html')

4. Enforce HTTPS and secure cookies in settings

Prevent credential interception and session fixation by tightening Django’s security settings. These Python-driven configurations reduce the impact of stolen credentials.

SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
SESSION_COOKIE_HTTPONLY = True

5. Integrate with Django’s authentication backends for extra checks

Custom backends can add device or risk-based checks before allowing authentication, making Python logic a gatekeeper for suspicious login patterns.

from django.contrib.auth.backends import ModelBackend

class RiskAwareBackend(ModelBackend):
    def authenticate(self, request, username=None, password=None, **kwargs):
        # Example: check request metadata or anomaly signals
        user = super().authenticate(request, username, password)
        if user and self.is_suspicious(request, user):
            return None
        return user

    def is_suspicious(self, request, user):
        # Implement your risk heuristics here
        return False