Password Spraying in Django with Bearer Tokens

Password spraying is an authentication attack where a single common password is tried against many accounts. In Django, this typically targets the login endpoint. When Bearer Tokens are used—commonly for API authentication via packages like djangorestframework-simplejwt or custom token handling—the presence of tokens does not prevent spraying if the API also supports username/password authentication. Attackers can attempt spraying against the password-based endpoint while using a Bearer Token to access protected endpoints that should otherwise require prior authentication.

Consider a Django REST Framework (DRF) project with token or JWT authentication configured alongside session-based login. If the token validation middleware does not block unauthenticated requests to the login route, a password spraying campaign can proceed against /api/login/ or similar. Each request includes a Bearer Token in the Authorization header for instrumentation or testing, but the spraying targets the unprotected credential check. For example, an attacker might send POST /api/login/ with username variations and a common password like Password123, while including a bearer token obtained from a previous or low-privilege source to probe rate-limiting behavior.

The vulnerability is compounded when tokens are issued after successful authentication but the system does not enforce strict origin checks or token binding. A sprayed password that succeeds on one account can lead to token issuance, allowing the attacker to pivot into API endpoints that rely on Bearer token validation. This creates a chain: spraying yields valid credentials, and valid credentials yield valid tokens, bypassing protections assumed to be enforced by token-only middleware.

Real-world mappings include the OWASP API Top 10 2023:7 — Identification and Authentication Failures, and the CWE-501 session fixation risk when tokens are accepted without re-authentication for sensitive actions. In a Django project using DRF, if the permission_classes for the login endpoint is not explicitly set to AllowAny with tight controls, spraying can leverage weak account policies such as missing lockouts or weak rate limiting.

An example request during spraying might include a Bearer token from a known service account to observe whether the API responds differently based on token validity rather than credential validity:

POST /api/login/ HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VybmFtZSI6InRlc3QifQ.XXXX

{"username": "jdoe", "password": "Password123"}

The token here may be valid but unrelated to the supplied username; the endpoint should validate credentials independently and not conflate token context with authentication state. Without proper separation, spraying outcomes can be misread, and successful authentication may be incorrectly attributed to token possession rather than password correctness.

Remediation focuses on strict separation of authentication mechanisms and robust controls on token usage. Ensure that the login endpoint explicitly requires no bearer token for password-based authentication attempts, and enforce rate limiting and account lockout independent of token validity.

First, configure permissions so that the login endpoint does not require a token. In Django REST Framework, use AllowAny for the serializer or view, but do not rely solely on this—add request-level throttling:

from rest_framework.throttling import AnonRateThrottle
from rest_framework.permissions import AllowAny
from rest_framework.views import APIView
from rest_framework.response import Response

class LoginView(APIView):
    permission_classes = [AllowAny]
    throttle_classes = [AnonRateThrottle]

    def post(self, request):
        # Your authentication logic here
        return Response({...})

Second, avoid accepting Bearer tokens for password verification. If using DRF with Simple JWT, ensure token validation is not applied to the login route by customizing authentication classes per view:

from rest_framework_simplejwt.authentication import JWTAuthentication
from rest_framework.permissions import IsAuthenticated

class ProtectedView(APIView):
    authentication_classes = [JWTAuthentication]
    permission_classes = [IsAuthenticated]

    def get(self, request):
        content = {"message": "Authenticated with bearer token"}
        return Response(content)

For the login view, omit JWTAuthentication so that tokens are not expected or validated during password checks.

Third, implement strict throttling on authentication endpoints to deter spraying, regardless of token presence. Use a custom throttle that limits attempts per username or IP:

from rest_framework.throttling import BaseThrottle

class SpraySafeThrottle(BaseThrottle):
    def __init__(self):
        self.history = {}  # Use cache/redis in production

    def allow_request(self, request, view):
        username = request.data.get("username", "")
        ip = request.META.get("REMOTE_ADDR")
        key = f"{username}:{ip}"
        # Simple in-memory count; replace with persistent store
        count = self.history.get(key, 0)
        if count >= 5:
            return False
        self.history[key] = count + 1
        return True

Finally, ensure tokens are bound to authentication events and not accepted as a shortcut. When issuing tokens, include the authentication method in claims and validate it on sensitive operations:

# Example token payload generation
import jwt
def create_token(user, method="password"):
    payload = {
        "sub": str(user.pk),
        "auth_method": method,
        "exp": datetime.datetime.utcnow() + datetime.timedelta(hours=1)
    }
    return jwt.encode(payload, "your-secret", algorithm="HS256")

Validate the auth_method on critical endpoints to prevent token misuse from sprayed credentials.