Use After Free in Django with Firestore

Use After Free (UAF) occurs when a program continues to use a pointer after the underlying object has been deallocated. In a Django context that uses Google Cloud Firestore, UAF is less about memory reclamation (since Python manages memory) and more about logical references to objects that are no longer valid or have been replaced. When a Firestore document or query result is cached, mutated, or iterated after a new query has reassigned the reference, stale data or empty results can be used in security-sensitive decisions, effectively creating a UAF-like logic bug.

Consider a Django view that retrieves a user profile from Firestore and then reuses a query variable without re-fetching. If the code caches a document snapshot and later reuses that variable after a write or a new query, it may operate on outdated data. For example, a permission check based on an old snapshot could incorrectly grant access because the snapshot reflects an earlier state that no longer matches the current Firestore document. This is a logical UAF: the application acts as if the old snapshot is authoritative, even though it has been logically invalidated by subsequent operations.

Another scenario involves Firestore transactions and retries. In a transaction, you read documents, compute a new value, and commit. If the transaction is retried due to a conflict, the local variables holding the read documents may be reused after the transaction has already committed or rolled back. Without re-reading inside the retry block, the transaction logic can apply updates based on stale data, leading to inconsistent security states or unintended mutations. This pattern is common in Django services that wrap Firestore transactions without properly scoping document references to the transaction lifecycle.

Insecure deserialization or unsafe consumption of Firestore data can also contribute to UAF-like behavior. If a Django model deserializes a Firestore document into a mutable object and that object is later modified or replaced without validation, other parts of the application may still hold references to the old object and make security decisions based on it. For instance, an access control list (ACL) stored as a map in Firestore may be read once and cached; if the Firestore document is updated to revoke permissions, the cached in-memory representation may not reflect the change, allowing unauthorized actions.

These issues map to the broader OWASP API Top 10 category of Security Misconfiguration and Broken Access Control. Because Firestore is a remote state store, the risk is not memory corruption but logical inconsistency that can be exploited to bypass authorization or leak data. middleBrick detects such patterns during unauthenticated scans by analyzing OpenAPI specs and runtime behavior, flagging endpoints where document references are reused across requests or where Firestore queries are not re-evaluated after state changes.

To prevent Use After Free-like issues with Firestore in Django, ensure that document references are fresh for each security-sensitive operation and that transactions do not rely on stale local variables. Always re-read documents inside the scope of the operation that uses them, and avoid caching Firestore snapshots across requests or retries unless you can guarantee their validity.

Example: safe Firestore fetch within a view

from google.cloud import firestore
from django.http import JsonResponse
from django.views import View

class ProfileView(View):
    def get(self, request, user_id):
        db = firestore.Client()
        doc_ref = db.collection("profiles").document(user_id)
        doc = doc_ref.get()
        if doc.exists:
            # Use the document data immediately; do not store doc for later use
            data = doc.to_dict()
            # Perform security checks here with fresh data
            if data.get("active"):
                return JsonResponse({"status": "ok", "profile": data})
        return JsonResponse({"error": "not found"}, status=404)

Example: transaction with local re-read

from google.cloud import firestore

def update_balance_with_retry(user_id, delta):
    db = firestore.Client()
    doc_ref = db.collection("accounts").document(user_id)

    @firestore.transactional
    def run_transaction(transaction):
        # Re-read inside the transaction to avoid stale references
        snapshot = doc_ref.get(transaction=transaction)
        if not snapshot.exists:
            raise ValueError("Account does not exist")
        current = snapshot.get("balance", 0)
        transaction.update(doc_ref, {"balance": current + delta})

    db.run_transaction(run_transaction)

Example: avoid caching Firestore documents across requests

# BAD: caching snapshot globally
_cached_profile = None

def get_profile_cached(user_id):
    global _cached_profile
    if _cached_profile is None:
        db = firestore.Client()
        _cached_profile = db.collection("profiles").document(user_id).get()
    return _cached_profile.to_dict()

# GOOD: fetch per request or use short-lived cache with TTL
from django.core.cache import cache

def get_profile_safe(user_id):
    cache_key = f"profile_{user_id}"
    cached = cache.get(cache_key)
    if cached is not None:
        return cached
    db = firestore.Client()
    doc = db.collection("profiles").document(user_id).get()
    if doc.exists:
        data = doc.to_dict()
        cache.set(cache_key, data, timeout=60)  # short TTL
        return data
    return None

By ensuring that Firestore reads are scoped to the operation and that transaction logic re-reads documents, you mitigate the risk of acting on invalidated or stale state. middleBrick’s scans can highlight endpoints where document references are reused across requests, helping you identify and refactor risky patterns.