Broken Access Control in Fastapi with Firestore

Broken Access Control occurs when API endpoints fail to enforce proper authorization checks, allowing one user to access or modify another user's resources. In a Fastapi application backed by Cloud Firestore, this risk is amplified when security rules and application-level checks are inconsistent or incomplete. Firestore’s flexible data model and rule system can inadvertently expose collections if rules are too permissive, while Fastapi routes may rely on incomplete or misordered authorization logic.

Consider a Fastapi endpoint that retrieves user data using a path parameter such as user_id. If the endpoint trusts the client-supplied user_id and only checks authentication (e.g., via an ID token) without verifying that the authenticated subject owns the requested resource, an attacker can enumerate or manipulate IDs to access other users' data. This is a classic BOLA/IDOR pattern. Firestore security rules can mitigate this at the database level, but rules must be explicit about matching the authenticated user’s UID to document fields or collection paths. If rules allow read access based only on collection existence or are scoped too broadly (e.g., allowing read on any document in a collection), the API surface remains vulnerable even when Fastapi code appears correct.

Real-world exploit chains often combine weak rule sets with missing runtime checks. For example, an attacker might send a request to GET /users/{user_id} with a valid JWT belonging to Alice but set user_id to Bob’s identifier. If Fastapi does not compare the token’s subject with the requested ID, and Firestore rules permit read access to any document in the users collection, Bob’s profile data is leaked. This aligns with OWASP API Top 10 A01:2023 broken access control and can expose PII, role assignments, or administrative flags stored in Firestore documents.

Additional risk arises from indirect references. Fastapi might use a public, guessable identifier (such as an integer) instead of a stable, unguessable UID, making enumeration feasible. If Firestore documents contain references to other collections (e.g., user_permissions), overly permissive rules may allow lateral movement across tenants. Misconfigured rules that use request.auth != null without validating ownership can also create privilege escalation paths, enabling a low-privilege user to read or write higher-privilege data.

Inconsistent validation between Fastapi and Firestore compounds the issue. For instance, Fastapi may validate a resource ID against an internal database but skip checks for auxiliary Firestore subcollections. An attacker could then target less-protected subcollections via the same API surface. Because Firestore rules operate independently from application code, developers must ensure both layers enforce the same ownership and scope constraints, applying the principle of least privilege at every access point.

Remediation centers on strict ownership checks in both Firestore security rules and Fastapi route logic. Firestore rules should enforce that a user can only access documents where a field such as uid or owner_id matches the authenticated subject’s UID. Fastapi should re-validate this ownership using the decoded JWT before performing any database operation, avoiding reliance on rules alone.

Example: a users collection where each document includes an owner_uid field. The Firestore rule ensures users can only read their own document:

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

In Fastapi, decode the ID token and compare its sub (or a mapped custom claim) to the path parameter before proceeding. Use the Firebase Admin SDK to verify tokens and enforce ownership programmatically:

from fastapi import FastAPI, Depends, HTTPException, status
from firebase_admin import auth, credentials, initialize_app, firestore
import os

cred = credentials.Certificate(os.getenv("FIREBASE_SERVICE_ACCOUNT"))
initialize_app(cred)

dep = FastAPI()
db = firestore.client()

async def get_current_user(token: str):
    try:
        return auth.verify_id_token(token)
    except auth.InvalidIdTokenError:
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="Invalid authentication token",
        )

@dep.get("/users/{user_id}")
async def read_user(user_id: str, token: str = Depends(get_current_user)):
    uid = token.get("sub")
    if not uid:
        raise HTTPException(status_code=401, detail="Missing user ID in token")
    if uid != user_id:
        raise HTTPException(status_code=403, detail="Access to this resource denied")
    doc_ref = db.collection("users").document(user_id)
    doc = doc_ref.get()
    if not doc.exists:
        raise HTTPException(status_code=404, detail="User not found")
    return doc.to_dict()

This pattern ensures that even if Firestore rules misbehave, the application layer still blocks unauthorized access. For operations involving collections, scope queries to the user’s documents using the UID:

@dep.get("/users/{user_id}/posts")
async def list_posts(user_id: str, token: str = Depends(get_current_user)):
    uid = token.get("sub")
    if uid != user_id:
        raise HTTPException(status_code=403, detail="Access denied")
    posts_ref = db.collection("users").document(user_id).collection("posts")
    snapshot = posts_ref.stream()
    return [doc.to_dict() for doc in snapshot]

For Firestore rules that use custom claims to denote roles, validate those claims in Fastapi as well before granting elevated operations. Avoid broad allow rules such as allow read: if true;; instead, scope writes to specific fields and require ownership or role checks. Combine rule-level constraints with runtime checks to achieve defense in depth, ensuring that both layers reject requests where the subject does not own the target resource.