Insecure Direct Object Reference in Flask with Firestore

Insecure Direct Object Reference (IDOR) occurs when an API exposes a reference to an internal object—such as a Firestore document ID—and allows an authenticated or unauthenticated actor to access or modify that object without proper authorization checks. In a Flask application that uses Google Cloud Firestore as a backend, this commonly arises when route parameters like user_id or document_id are directly used to construct Firestore paths or queries without validating that the requesting subject has permission to access that specific document.

Consider a Flask route that retrieves a user profile using a URL parameter:

@app.route('/api/users/<user_id>')
def get_user(user_id):
    # Vulnerable: directly using user_id from the URL
    doc_ref = firestore_client.collection('users').document(user_id)
    doc = doc_ref.get()
    if doc.exists:
        return jsonify(doc.to_dict()), 200
    return jsonify({'error': 'not found'}), 404

If the route relies only on authentication (e.g., a valid session or token) and does not verify that the authenticated user is allowed to view the requested user_id, an IDOR vulnerability exists. An attacker who knows or guesses another user’s ID can enumerate profiles or sensitive data. This risk is compounded when Firestore security rules are misconfigured or not enforced at query time, and when the application layer assumes the client-supplied ID is trustworthy.

IDOR can also manifest in list-like endpoints where a user can iterate over numeric offsets or non-sequential IDs to access collections they should not see. For example, an endpoint that lists billing records might accept a customer_id parameter and query:

customers_ref = firestore_client.collection('customers').document(customer_id).collection('billing')

If the application does not confirm that the authenticated tenant or user has access to that customer_id, the attacker can traverse unrelated customer billing records. Because Firestore document IDs are often predictable or enumerable, IDOR in this context can lead to mass data exposure across tenants or organizations.

In unauthenticated scenarios, if a Firestore collection is mistakenly left open and a Flask route exposes document IDs without any access control, the issue becomes even more severe. Attackers can scrape or fuzz IDs to harvest data, a pattern commonly flagged under BOLA (Broken Object Level Authorization) in API security assessments.

Remediation focuses on enforcing authorization checks in application logic and ensuring Firestore queries are constrained by the subject’s identity. Never trust client-supplied IDs; instead, derive document references from the authenticated subject’s identity or mapped relationships.

1) Enforce ownership checks using the authenticated user’s ID

Replace direct ID usage with a lookup that ties the resource to the authenticated subject. For example, if your users collection stores documents keyed by user IDs and you use Firebase Auth or a session store to identify the current user:

from flask import request, jsonify
import firebase_admin
from firebase_admin import credentials, firestore

cred = credentials.Certificate('path/to/serviceAccountKey.json')
firebase_admin.initialize_app(cred)
db = firestore.client()

@app.route('/api/users/me')
def get_current_user():
    # Obtain user identity from your auth/session layer
    current_user_id = get_authenticated_user_id(request)  # implement this
    if not current_user_id:
        return jsonify({'error': 'unauthorized'}), 401
    # Reference is derived, not user-controlled
    doc_ref = db.collection('users').document(current_user_id)
    doc = doc_ref.get()
    if doc.exists:
        return jsonify(doc.to_dict()), 200
    return jsonify({'error': 'not found'}), 404

2) Validate tenant or organizational scope before querying related collections

When accessing nested collections such as billing, ensure the parent document is owned or shared with the requesting tenant:

@app.route('/api/customers/<customer_id>/billing')
def list_billing(customer_id):
    user_id = get_authenticated_user_id(request)
    if not user_id:
        return jsonify({'error': 'unauthorized'}), 401
    # Assume a mapping collection or field links user to allowed customers
    user_customer_ref = db.collection('user_customer_mapping').document(user_id).collection('customers').document(customer_id)
    mapping_doc = user_customer_ref.get()
    if not mapping_doc.exists:
        return jsonify({'error': 'forbidden'}), 403
    # Safe to query because mapping validated access
    billing_ref = db.collection('customers').document(customer_id).collection('billing')
    results = billing_ref.stream()
    items = [r.to_dict() for r in results]
    return jsonify(items), 200

3) Use server-side IDs and avoid exposing Firestore document IDs directly in APIs

Instead of returning or accepting raw Firestore document IDs, use internal mapping tables or opaque identifiers. If you must expose an ID, map it server-side to a canonical key:

@app.route('/api/records/<record_key>')
def get_record(record_key):
    user_id = get_authenticated_user_id(request)
    # Translate key to Firestore document ID securely
    record_meta = db.collection('record_mapping').where('user_id', '=='user_id).where('key', '=='record_key).limit(1).stream()
    for entry in record_meta:
        doc_id = entry.to_dict().get('document_id')
        doc_ref = db.collection('records').document(doc_id)
        doc = doc_ref.get()
        if doc.exists:
            return jsonify(doc.to_dict()), 200
    return jsonify({'error': 'not found or forbidden'}), 404

These patterns align with the checks in the middleBrick’s BOLA/IDOR and Property Authorization tests, which evaluate whether object references are subject-bound and whether authorization is enforced at the query layer. By coupling identity derivation with Firestore reads and validating mappings before queries, you reduce the attack surface significantly.