Credential Stuffing in Django with Bearer Tokens

Credential stuffing is an automated attack where previously breached username and password pairs are reused to gain unauthorized access. When Bearer Tokens are used in a Django API, a common anti-pattern is to treat the token as a static, long-lived credential after the initial login. If the token is stored client-side without proper binding to the client instance and without rotation, an attacker can harvest these tokens and replay them against the API. Unlike session cookies, Bearer Tokens are not automatically protected by browser same-site attributes, so they can be more easily exfiltrated via XSS or insecure storage and then reused across services.

In Django, developers might implement token authentication using packages like Django REST Framework’s TokenAuthentication or custom JWT-based schemes. A vulnerability arises when tokens are issued without considering scope, audience, or client IP binding. For example, a token issued after a successful login might be accepted from any IP and any user-agent, enabling credential stuffing bots to iterate over stolen tokens. Additionally, if the token endpoint does not enforce strong rate limiting or anomaly detection, attackers can perform high-volume token replay attempts without triggering defenses. The Django application may also lack adequate monitoring for repeated authentication failures or token validation anomalies, allowing low-and-slow credential stuffing campaigns to persist.

Consider a scenario where an API endpoint relies on a Bearer Token passed in the Authorization header without additional context checks. An attacker with a list of token-user pairs can script requests to probe whether any token remains valid across different user contexts. Because the token itself may not encode sufficient binding to a particular client or session, the attack surface is widened. Furthermore, if Django’s token validation logic does not verify token revocation status or does not check for token reuse across sessions, the effectiveness of credential stuffing is amplified. This is especially dangerous when tokens are long-lived or when refresh tokens are not properly invalidated after use.

Remediation focuses on binding tokens to client context, shortening lifetimes, and enforcing strict validation in Django. Instead of relying solely on a static Bearer token, implement token binding using claims such as scope, client_id, and ip_hash when validating requests. Use short-lived access tokens and rotate refresh tokens securely. Below is a concrete example of a custom Bearer token validation middleware in Django that incorporates these principles.

import hashlib
import time
from django.http import JsonResponse
from django.utils.deprecation import MiddlewareMixin

def generate_token_hash(token, client_ip):
    return hashlib.sha256(f"{token}:{client_ip}".encode()).hexdigest()

class BearerTokenValidationMiddleware(MiddlewareMixin):
    def process_request(self, request):
        auth_header = request.META.get('HTTP_AUTHORIZATION', '')
        if auth_header.startswith('Bearer '):
            token = auth_header.split(' ')[1]
            client_ip = request.META.get('REMOTE_ADDR', '')
            token_hash = generate_token_hash(token, client_ip)
            # Validate token against a model that stores token_hash, expiry, and scope
            from .models import ValidatedToken
            try:
                validated_token = ValidatedToken.objects.get(token_hash=token_hash, revoked=False)
                if validated_token.expiry < time.time():
                    return JsonResponse({'error': 'token_expired'}, status=401)
                # Optionally enforce scope-based access
                if 'api:read' not in validated_token.scope.split(','):
                    return JsonResponse({'error': 'insufficient_scope'}, status=403)
                request.user_token = validated_token
            except ValidatedToken.DoesNotExist:
                return JsonResponse({'error': 'invalid_token'}, status=401)
        return None

This approach ensures that each token is bound to the client’s IP address, mitigating replay attacks from different network locations. The token hash is stored in the database alongside an expiry timestamp and a scope string, enabling fine-grained access control. In your Django models, define a ValidatedToken entity that records these attributes and provides mechanisms for revocation and rotation.

Additionally, strengthen the token issuance flow by validating client credentials during token creation and avoiding overly permissive scopes. Combine this with rate limiting at the API gateway or Django middleware layer to deter high-volume credential stuffing attempts. For production deployments, integrate logging and alerting to detect repeated invalid token attempts, which may indicate an ongoing attack. Tools like the middleBrick CLI can be used to scan your Django API endpoints and surface authentication and token validation misconfigurations before they are exploited.