Time Of Check Time Of Use in Django with Bearer Tokens

Time Of Check Time Of Use (TOCTOU) is a class of race condition where a system checks a condition (such as authentication or authorization) and later uses the result of that check to make a security decision. When this pattern is applied to API authentication using Bearer Tokens in Django, the window between the check and the use can be exploited if the token state can change between these steps.

Consider a typical Django view that validates a Bearer Token from the Authorization header, checks permissions, and then proceeds to perform an action. A vulnerable flow might look like this: the request is first authenticated by verifying the token against a database or cache to confirm it is active and not revoked; immediately afterward, the view queries the database for the user or resource and performs the operation. If an attacker can cause the token to be revoked or swapped between the authentication check and the data access, the check passes but the use proceeds with a now-invalid or different identity. This can lead to horizontal or vertical privilege escalation, access to other users' data, or unauthorized state changes.

Django REST framework (DRF) commonly handles Bearer Tokens via custom authentication classes. In a naive implementation, you might authenticate the token, attach a user to the request, and later rely on request.user to enforce object-level permissions. However, if the token validation queries a database or cache that can be changed at runtime (for example, via an admin action, another compromised session, or token revocation logic) and the permission checks do not re-verify the token’s validity at the moment of data access, a TOCTOU gap exists. This is especially relevant when token state is stored externally and can be modified by administrative tools or other services, allowing an attacker to revoke or replace the token after authentication but before critical operations.

The risk is compounded when authorization logic assumes that request.user derived from the token will remain stable for the duration of the request. If views perform secondary checks only on user attributes (such as is_staff or group membership) and do not re-validate the token or re-fetch the latest token status at the point of data access, an attacker who can influence the backend token state may bypass intended protections. For example, an attacker could authenticate with a valid Bearer Token, trigger a revocation or role change via another vector, and then exploit a privileged operation that still executes because the view trusted the earlier, now stale, check.

Real-world scenarios align with common API security weaknesses cataloged in the OWASP API Security Top 10, such as Broken Object Level Authorization (BOLA), where insufficient object-level checks allow unauthorized access. TOCTOU in the context of Bearer Tokens is not a theoretical flaw; it can be triggered in systems where token metadata is mutable and authorization does not re-consume the token state at each sensitive operation. Because middleBrick tests for BOLA/IDOR and Authentication in parallel, such race conditions can be surfaced when scanning endpoints that rely on token state without re-verification at use time.

To mitigate TOCTOU for Bearer Tokens in Django, ensure that authorization decisions are made with the most up-to-date token and user state at the point of use. Avoid relying on request.user set once by authentication middleware if the token’s backend state can change. Instead, re-validate the token and re-associate the user (or at least re-check critical permissions) inside sensitive operations, especially those involving object-level access.

One approach is to create a lightweight helper that re-freshes the user and token validity using the current Authorization header. For example:

import requests
from django.conf import settings
from django.contrib.auth.models import User
from rest_framework_simplejwt.tokens import AccessToken

def get_current_user_from_token(request):
    auth_header = request.headers.get('Authorization', '')
    if not auth_header.startswith('Bearer '):
        return None
    token = auth_header.split(' ')[1]
    try:
        # Validate token structure and fetch latest claims
        access_token = AccessToken(token)
        user_id = access_token["user_id"]
        # Re-query the database to ensure the user and token are still valid
        user = User.objects.filter(pk=user_id).first()
        if user is None:
            return None
        # Optional: check a per-request revocation list or token version in cache/db
        # if is_token_revoked(token, user_id):
        #     return None
        return user
    except Exception:
        return None

Use this helper in views that perform sensitive actions, rather than trusting request.user set earlier. For example:

from django.http import JsonResponse, HttpResponseForbidden
from django.views import View

class SensitiveDataView(View):
    def get(self, request, resource_id):
        current_user = get_current_user_from_token(request)
        if not current_user:
            return HttpResponseForbidden('Invalid or expired token')
        # Re-check object-level permissions with the fresh user
        try:
            obj = UserResource.objects.get(id=resource_id, owner=current_user)
        except UserResource.DoesNotExist:
            return HttpResponseForbidden('Access denied')
        # Proceed only if the token and permissions are valid at this moment
        return JsonResponse({'data': str(obj)})

For DRF-based APIs, customize authentication to re-validate on each request when necessary, or use a permission class that re-checks token status and object ownership immediately before allowing access:

from rest_framework import permissions
from rest_framework_simplejwt.tokens import AccessToken
from django.contrib.auth import get_user_model

User = get_user_model()

class TokenOwnershipPermission(permissions.BasePermission):
    def has_object_permission(self, request, view, obj):
        auth_header = request.headers.get('Authorization', '')
        if not auth_header.startswith('Bearer '):
            return False
        token = auth_header.split(' ')[1]
        try:
            access_token = AccessToken(token)
            user_id = access_token['user_id']
            # Re-fetch the object and ensure ownership with the latest token-user mapping
            return obj.owner_id == user_id
        except Exception:
            return False

Additionally, prefer short-lived Bearer Tokens and implement token revocation checks using a fast cache or database lookup at the point of use to invalidate tokens immediately when necessary. Combine these practices with strong input validation and rate limiting to reduce the window and impact of any potential race conditions.