Use After Free in Fastapi with Jwt Tokens

Use After Free occurs when a program continues to use memory after it has been freed. In the context of FastAPI applications that use JWT tokens for authentication, the risk is not typically in the runtime memory management of Python itself, but in how token payloads are deserialized, stored, and compared. A Use After Free pattern can emerge indirectly when token handling logic retains references to objects that should be invalidated or replaced after logout or privilege change, especially when mutable payloads are cached or reused across requests.

Consider a FastAPI implementation that decodes a JWT token into a Python dictionary and stores that dictionary in a global cache keyed by the token identifier (e.g., jti claim). If a user logs out or their permissions are revoked, the server may remove the entry from an active session store but still retain a reference in an in‑memory dictionary or a long‑lived background structure. A later request with a valid JWT but stale cached data could then be mistakenly authorized based on outdated or already‑freed session state, effectively creating a Use After Free scenario where the application acts on information that should no longer be trusted.

Another concrete pattern arises when custom JWT validation logic uses mutable objects for claims and passes them between asynchronous tasks without proper isolation. For example, decoding a token into a dict and attaching it to a request state object that persists across middleware or dependency calls can lead to the same underlying issue: the application may reference a payload that has conceptually been invalidated (e.g., after a token rotation or revocation), causing authorization decisions to be made on freed or reused data. This is especially relevant when combined with IDOR or BOLA flaws, where an attacker can manipulate identifiers to force the server to operate on incorrect or released references.

JWT tokens themselves do not carry runtime memory, but the way their payloads are handled in FastAPI can create conditions where stale or invalid references are used in security‑critical checks. For instance, if a token is blacklisted after logout but the blacklist check is bypassed due to a logic error, or if the decoded payload is cached and reused after a revocation, the application may behave as though the token is still valid. This intersects with common API vulnerabilities such as Insecure Direct Object References (IDOR) and Broken Object Level Authorization (BOLA), where improper authorization checks allow one user to access another’s resources.

Real attack patterns often chain JWT handling flaws with other weaknesses. An attacker might exploit improper cache invalidation to escalate privileges by reusing a token payload that should have been invalidated, or by forcing the server to deserialize and validate tokens in an unsafe order. These scenarios map to OWASP API Top 10 categories, including Broken Object Level Authorization and Security Misconfiguration. Because FastAPI applications often rely on dependency injection and global state for performance, developers must ensure that token‑related data is not shared across requests in a way that creates lingering references to invalidated sessions.

Remediation focuses on ensuring that token payloads are treated as immutable values, isolating per‑request state, and avoiding long‑lived references to decoded claims. The following examples demonstrate secure patterns for JWT handling in FastAPI.

First, always decode and validate the token within the scope of the request, and avoid storing the decoded payload in global or static structures. Use FastAPI’s Depends to create a fresh, request‑local context:

from fastapi import Depends, FastAPI, HTTPException, status
from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials
import jwt
from typing import Dict

app = FastAPI()
security = HTTPBearer()

def decode_token(credentials: HTTPAuthorizationCredentials = Depends(security)) -> Dict:
    token = credentials.credentials
    try:
        payload = jwt.decode(token, "your-secret-key", algorithms=["HS256"])
        # Do not cache or store payload globally; return a plain dict per request
        return payload
    except jwt.ExpiredSignatureError:
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED, detail="Token expired"
        )
    except jwt.InvalidTokenError:
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED, detail="Invalid token"
        )

@app.get("/secure")
def secure_endpoint(payload: Dict = Depends(decode_token)):
    # Use payload locally; do not assign to a global cache
    user_id = payload.get("sub")
    return {"user": user_id, "status": "ok"}

Second, if token revocation or logout is required, maintain a server‑side revocation list keyed by token identifiers (jti) with strict TTLs, and validate on each request without referencing the payload after it has been checked:

import time
from fastapi import Depends

revoked_jti: set[str] = set()

def is_token_revoked(jti: str) -> bool:
    # In production, use a fast cache like Redis with TTL matching token expiry
    return jti in revoked_jti

def validate_token(credentials: HTTPAuthorizationCredentials = Depends(security)):
    payload = decode_token(credentials)
    jti = payload.get("jti")
    if jti is None or is_token_revoked(jti):
        raise HTTPException(status_code=401, detail="Token revoked")
    # Immediately use payload and discard; do not retain beyond this function
    return payload

Third, ensure that any background tasks or async operations do not capture mutable references to decoded tokens. Pass immutable copies or primitive values instead:

from copy import deepcopy

def schedule_token_audit(token_payload: Dict):
    # Create an immutable snapshot if you must log or process later
    snapshot = deepcopy(dict(token_payload))
    # Send snapshot to a queue or logging system; do not store the original payload
    audit_queue.put(snapshot)

Finally, map these practices to compliance frameworks by documenting how token validation aligns with OWASP API Top 10 controls, and consider adding API security checks via the middleBrick CLI to verify that your endpoints do not exhibit risky token handling patterns.