Insecure Design in Django with Firestore

Insecure design in a Django application that uses Google Cloud Firestore as its primary data store often stems from conflating Django’s relational mental model with Firestore’s document-based, schema-less model. This mismatch can lead to designs that overtrust the client, perform unsafe data transformations, and fail to enforce authorization at the database layer.

One common pattern is deserializing incoming JSON directly into Django models and then writing that data into Firestore without validating field ownership or access context. Because Firestore does not enforce row-level security the way a relational database might with application-level constraints, the onus is on the Django layer to ensure that a user can only read or write documents they are permitted to access. If the design assumes Firestore paths like users/{uid}/data are inherently safe simply because the path includes the user ID, the app may fail to validate that the authenticated request’s user ID matches the path segment on every operation. This becomes a Broken Level of Authorization (BOLA/IDOR) vector when an attacker iterates over other user IDs.

Another insecure design is using Firestore for role or permission data that should be verified server-side. For example, storing a user’s role in a Firestore document and relying solely on client-supplied claims or cached values can allow privilege escalation if the client tampers with the role. Django middleware or decorators might check a role flag retrieved from Firestore once, but if the design does not re-validate that role on each sensitive action, an attacker can escalate privileges by modifying the cached value or replaying an older token with elevated scopes.

The combination also encourages unsafe indexing and querying patterns. Developers sometimes build dynamic queries using string concatenation on Firestore collection and document IDs, which can open the door to injection-like behavior or unintended data access if inputs are not strictly validated. Firestore’s query capabilities are powerful but require strict input validation and type checking; without it, an attacker can manipulate query parameters to enumerate data or bypass intended filters. Finally, logging or error handling designs that expose Firestore document IDs or internal paths in responses can leak information that aids further attacks, violating data exposure principles.

Remediation centers on strict input validation, canonical path construction, and server-side authorization checks before any Firestore interaction. Always resolve Firestore document references using server-controlled identifiers rather than client-provided values, and enforce ownership at the point of access.

Example: Safe document path resolution

Instead of concatenating user input into a Firestore path, derive the document reference from the authenticated user’s canonical ID. In Django, integrate with the authentication backend to obtain the user’s stable UID and build the reference server-side:

from google.cloud import firestore
from django.contrib.auth import get_user

def get_user_data_ref(user_id: str):
    # Validate and normalize user_id (e.g., UUID format check)
    if not isinstance(user_id, str) or not user_id.strip():
        raise ValueError("Invalid user identifier")
    db = firestore.Client()
    return db.collection('users').document(user_id).collection('data')

# Usage in a view
from django.http import JsonResponse
from django.views import View

class UserDataView(View):
    def get(self, request):
        user = request.user  # Authenticated Django user
        ref = get_user_data_ref(user.uid)
        docs = ref.stream()
        items = [doc.to_dict() for doc in docs]
        return JsonResponse(items, safe=False)

Example: Enforcing ownership and validation on write

When creating or updating a document, ensure the path matches the authenticated user and validate all incoming fields against a strict schema. Use server-side checks before committing writes:

from google.cloud import firestore
from django.core.exceptions import PermissionDenied

def update_user_profile(user_id: str, payload: dict):
    # Strict schema validation (example using basic checks)
    allowed_fields = {'display_name', 'email_opt_in'}
    if not set(payload.keys()).issubset(allowed_fields):
        raise ValueError('Invalid fields supplied')
    if not isinstance(user_id, str) or len(user_id) != 36:  # UUID example
        raise ValueError('Malformed user ID')
    db = firestore.Client()
    doc_ref = db.collection('users').document(user_id).collection('profile).document('current')
    # Authorization: ensure the user_id matches the authenticated context
    # (In practice, compare with request.user.uid on the server)
    doc_ref.set(payload)

# In a Django view
from django.views import View
from django.http import JsonResponse

class ProfileUpdateView(View):
    def post(self, request):
        user = request.user
        payload = request.POST.dict()
        try:
            update_user_profile(user.uid, payload)
            return JsonResponse({'status': 'ok'})
        except (ValueError, PermissionDenied) as e:
            return JsonResponse({'error': str(e)}, status=400)

Example: Server-side role checks before sensitive operations

Do not rely on client-provided role claims. Fetch role metadata from Firestore under server control and re-evaluate on each sensitive action:

def has_permission(user_id: str, required_role: str):
    db = firestore.Client()
    role_doc = db.collection('roles').document(user_id).get()
    if not role_doc.exists:
        return False
    role_data = role_doc.to_dict()
    return role_data.get('role') == required_role

class AdminActionView(View):
    def post(self, request):
        user = request.user
        if not has_permission(user.uid, 'admin'):
            raise PermissionDenied('Admin access required')
        # Proceed with admin logic
        return JsonResponse({'result': 'success'}))

General secure design practices

• Treat Firestore paths as opaque server-managed identifiers; avoid exposing raw document IDs in URLs unless they are canonical and validated.
• Apply strict input validation and type checks on all query parameters and request bodies before constructing Firestore queries.
• Log audit events server-side with minimal sensitive data; avoid including full document contents or internal paths in logs returned to clients.
• Use Firestore’s built-in mechanisms (e.g., security rules for read/write) as a complementary layer, but enforce critical authorization in Django to avoid reliance on client-side rules alone.