Token Leakage in Django with Firestore

Token leakage occurs when authentication or session tokens are exposed beyond their intended boundary, enabling unauthorized access. In a Django application that integrates with Google Cloud Firestore, the risk arises at the intersection of Django’s identity management and Firestore’s credential handling.

Django typically relies on session cookies or JWTs for web authentication. If tokens such as API keys for Firestore or OAuth tokens are embedded in URLs, client-side JavaScript, or logs, they can be exfiltrated through referer headers, browser history, or log injection. Firestore, when accessed via the official google-cloud-firestore Python client, requires a service account key or Application Default Credentials (ADC). If credentials are loaded from environment variables or configuration files that are inadvertently exposed—such as through debug pages, error messages, or insecure deployment scripts—an attacker can harvest the token and assume the associated identity.

Another vector specific to this combination is improper use of Firestore security rules. Rules that fail to validate the requesting user’s identity can allow token use across users. For example, if a mobile or single-page frontend obtains a user’s Firebase ID token and passes it to Django as an authorization bearer token, but Django does not verify the token’s audience, issuer, or signature, a tampered or replayed token may grant elevated access to Firestore paths that should be restricted.

Additionally, logging and monitoring integrations can inadvertently store tokens. If Django logs incoming requests including authorization headers before passing them to Firestore, and those logs are aggregated in a searchable system, tokens may persist in plaintext. Because Firestore operations are often performed with a shared service account, leakage of one token can expose multiple datasets, violating the principle of least privilege and enabling lateral movement.

The 12 security checks in middleBrick align with this risk profile: Authentication, BOLA/IDOR, and Data Exposure checks can identify token leakage vectors; Input Validation and Unsafe Consumption can detect insecure handling of tokens in requests; LLM/AI Security can uncover prompt or token leakage in AI-assisted components; and Rate Limiting can mitigate brute-force attempts on exposed endpoints.

Remediation focuses on strict token handling, secure credential management, and disciplined rule design. Below are concrete, secure patterns for a Django service that reads and writes to Firestore.

1. Secure credential initialization

Never load service account keys via environment variables that may leak into logs or error traces. Instead, use Application Default Credentials in a controlled manner and restrict the scope of the service account.

import os
from google.cloud import firestore
from google.auth.exceptions import DefaultCredentialsError

def get_firestore_client():
    # Use ADC only in trusted runtime environments (e.g., Cloud Run, GKE with workload identity)
    try:
        client = firestore.Client(project=os.getenv('GCP_PROJECT'))
        return client
    except DefaultCredentialsError:
        # Explicit fallback only for local development with a restricted key file
        if os.getenv('DJANGO_SETTINGS_MODULE') == 'myapp.settings.dev':
            return firestore.Client.from_service_account_json('/secrets/dev-firestore.json')
        raise

2. Token validation for incoming requests

If your frontend supplies an ID token (e.g., Firebase ID token), validate it before using it to authorize Firestore operations. Do not treat the token as equivalent to a Django session.

import firebase_admin
from firebase_admin import auth, credentials
from django.http import HttpResponseForbidden

# Initialize once at module level
if not firebase_admin._apps:
    cred = credentials.Certificate('/secrets/firebase-service-account.json')
    firebase_admin.initialize_app(cred, {'databaseURL': 'https://myapp.firebaseio.com'})

def validate_id_token(token: str):
    try:
        decoded_token = auth.verify_id_token(token)
        return decoded_token  # contains uid, email, etc.
    except ValueError:
        return None

def my_view(request):
    auth_header = request.META.get('HTTP_AUTHORIZATION')
    if not auth_header or not auth_header.startswith('Bearer '):
        return HttpResponseForbidden('Missing token')
    token = auth_header.split(' ')[1]
    user = validate_id_token(token)
    if not user:
        return HttpResponseForbidden('Invalid token')
    # Proceed with Firestore operations using user['uid']

3. Principle-of-least-privilege Firestore rules

Define rules that scope access to user-specific documents and enforce ownership checks. Avoid wildcard reads/writes.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
    match /public/{docId} {
      allow read: if true;
      allow write: if request.auth != null && request.auth.token.role == 'admin';
    }
  }
}

4. Safe request handling and output sanitization

Avoid logging authorization headers and sanitize any data sent to clients to prevent token exfiltration via XSS or log scraping.

import logging
logger = logging.getLogger(__name__)

def api_handler(request):
    # Do NOT log Authorization header
    logger.info('Request processed', extra={'path': request.path, 'method': request.method})
    # ... business logic