Identification Failures in Django with Bearer Tokens

An Identification Failure occurs when an API or application fails to properly identify the requesting entity, allowing one user to access another user’s resources. In Django, using Bearer Tokens for authentication can introduce this class of vulnerability when token validation is incomplete, overly permissive, or misapplied. A common root cause is relying solely on the presence of a token without enforcing strict scope, audience, or user-bound checks. For example, if a view only verifies that a token is valid but does not ensure the token’s subject (sub) or associated user ID is checked against the requested resource, an attacker can reuse another user’s token to bypass ownership checks.

Consider a standard token-based setup in Django where a token is passed in the Authorization header as Bearer <token>. If the token validation logic decodes the token but does not map the token’s claims to a Django user and enforce per-request authorization, the endpoint may inadvertently treat any authenticated token as equivalent. This becomes an Identification Failure when the endpoint also lacks object-level permissions: an attacker who obtains a valid token (e.g., via leakage or a compromised client) can iterate through IDs (BOLA/IDOR) and access or modify data belonging to other users because the backend never confirms that the token’s user matches the target resource’s owner.

Django REST Framework (DRF) with packages like djangorestframework-simplejwt or custom JWT handling can be misconfigured in ways that enable this. For instance, if the token verification step does not bind the token to a specific user record in the database, or if the permission classes only check for authentication and not ownership, the attack surface expands. An attacker can capture or guess a valid Bearer token and make requests such as GET /api/users/123/ while the token actually belongs to user 456. Without a permissive CORS policy or host-header validation, this can be exploited in cross-context scenarios where tokens are leaked through logs or browser storage.

The interaction with Django’s permission system is critical. Using IsAuthenticated alone is insufficient; you must pair it with object-level checks or custom permissions that assert the requesting user derived from the token matches the resource owner. Failure to do so means the framework’s authentication layer reports success while the authorization layer is effectively bypassed. Additionally, if token introspection or revocation is not implemented, stolen or leaked tokens remain valid until expiry, increasing the window for Identification Failures. This is especially relevant when tokens have long lifetimes or are not bound to a specific scope or audience, allowing broader reuse across endpoints than intended.

To detect this during a scan, middleBrick runs checks that compare authentication mechanisms with authorization enforcement. It examines whether token-based authentication is coupled with user-bound validation and whether endpoints correctly resolve the user from the token and enforce ownership. The scanner also tests for BOLA/IDOR patterns by probing endpoints with different identifiers while using the same Bearer token to see if access is improperly granted. These tests highlight cases where identification fails not due to a broken token format, but due to missing or incomplete linkage between token claims and Django user/resource identity.

Remediation focuses on ensuring that every authenticated request maps the Bearer token to a concrete user and that authorization checks validate ownership or scope before data access. Start by using a well-a maintained library such as djangorestframework-simplejwt and configure token claims to include a user identifier (e.g., user_id). Always verify the token on each request and resolve the Django user from your token validation logic rather than relying on a cached or loosely tied user object.

Example of secure token validation and user resolution in Django REST Framework views:

from rest_framework.views import APIView
from rest_framework.permissions import IsAuthenticated
from rest_framework.response import Response
from rest_framework import status
from django.contrib.auth import get_user_model
import jwt
from django.conf import settings

User = get_user_model()

class SecureUserDetailView(APIView):
    permission_classes = [IsAuthenticated]

    def get_object(self, user_id):
        try:
            return User.objects.get(pk=user_id)
        except User.DoesNotExist:
            return None

    def get(self, request, user_id):
        # Decode and validate the Bearer token on each request
        auth_header = request.headers.get('Authorization')
        if not auth_header or not auth_header.startswith('Bearer '):
            return Response({'detail': 'Authorization header missing or malformed'}, status=status.HTTP_401_UNAUTHORIZED)

        token = auth_header.split(' ')[1]
        try:
            payload = jwt.decode(token, settings.SECRET_KEY, algorithms=['HS256'], audience='api', options={'verify_exp': True})
            token_user_id = payload.get('user_id')
            if token_user_id is None:
                return Response({'detail': 'Token does not contain user identifier'}, status=status.HTTP_401_UNAUTHORIZED)
        except jwt.ExpiredSignatureError:
            return Response({'detail': 'Token expired'}, status=status.HTTP_401_UNAUTHORIZED)
        except jwt.InvalidTokenError:
            return Response({'detail': 'Invalid token'}, status=status.HTTP_401_UNAUTHORIZED)

        # Ensure the token user matches the requested resource
        if token_user_id != user_id:
            return Response({'detail': 'Forbidden: token user does not match requested user'}, status=status.HTTP_403_FORBIDDEN)

        user = self.get_object(user_id)
        if user is None:
            return Response({'detail': 'User not found'}, status=status.HTTP_404_NOT_FOUND)

        return Response({'id': user.id, 'username': user.username})

Key points in this example:

• The Authorization header is explicitly checked for the Bearer scheme.
• The JWT is decoded with audience verification and expiration checks to prevent replay and misuse.
• The user_id claim in the token is compared with the user_id in the URL, ensuring the token owner matches the requested resource.
• Permission classes like IsAuthenticated remain as a baseline, but object-level checks are enforced in the view logic.

Additionally, apply per-view or per-method permission classes that assert ownership, and use scopes to limit what each token can do. For broader protection, implement token revocation and short lifetimes, and avoid storing tokens in insecure locations. middleBrick’s scans validate these patterns by checking whether authentication is tied to authorization and whether endpoints expose data without confirming user context.