Broken Access Control in Flask with Firestore

Broken Access Control occurs when API endpoints fail to enforce proper authorization checks, allowing one user to act on another user’s resources. In a Flask application using Google Cloud Firestore, this risk is amplified when application logic relies on client-supplied identifiers (such as user IDs or document paths) without validating that the authenticated principal is permitted to access those resources.

Flask does not provide built-in authorization; developers must implement access rules explicitly. When Firestore documents are organized per user (e.g., users/{user_id}/data/{document_id}), it is common to retrieve a document ID from the request (e.g., via URL parameters or JSON body) and construct a Firestore path using that ID. If the application does not verify that the requesting user matches the intended user segment of the path, an attacker can modify the ID to access or modify another user’s data. This is a classic BOLA/IDOR pattern, and middleBrick flags it under the BOLA/IDOR check among its 12 security checks.

Consider a Flask route that fetches a user profile document using a user-supplied user_id:

from flask import Flask, request, jsonify
import google.auth.transport.requests
import google.oauth2.id_token
import firebase_admin
from firebase_admin import credentials, firestore

app = Flask(__name__)
cred = credentials.Certificate('service-account.json')
firebase_admin.initialize_app(cred)
db = firestore.client()

@app.route('/api/profile/', methods=['GET'])
def get_profile(user_id):
    # Vulnerable: no check that the authenticated user matches user_id
    doc = db.collection('users').document(user_id).get()
    if doc.exists:
        return jsonify(doc.to_dict())
    return jsonify({'error': 'not found'}), 404

In this example, an attacker can change <user_id> in the URL to access any user’s profile, provided the Firestore security rules allow the service account credentials used by the application to read documents. Because this scan tests the unauthenticated attack surface, middleBrick would identify the missing ownership check as a high-severity finding under the BOLA/IDOR category.

The combination of Flask’s flexibility in routing and Firestore’s hierarchical, permission-rich data model creates opportunities for Insecure Direct Object References (IDOR). If Firestore security rules are misconfigured to allow broad read or write access from the application’s service account, the vulnerability can lead to mass data exposure. middleBrick’s Data Exposure and Property Authorization checks are designed to surface such rule misconfigurations by cross-referencing your OpenAPI spec definitions with runtime behavior.

Additionally, if the API exposes Firestore document IDs or collection names in responses or error messages, it may inadvertently aid an attacker in mapping the data model. Proper access control must therefore include verifying the authenticated user’s identity against the resource’s ownership metadata, using server-side mappings rather than trusting client-provided keys alone.

To fix Broken Access Control in Flask with Firestore, enforce strict ownership checks on the server side and avoid relying on client-supplied identifiers for authorization. Always resolve the authenticated user’s identity from the session or token, and compare it against the resource’s owning user ID stored in Firestore.

Below is a secure implementation that retrieves the authenticated user’s ID from a validated token (for example, an ID token from a frontend) and ensures that the requested profile belongs to that user:

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

app = Flask(__name__)
cred = credentials.Certificate('service-account.json')
firebase_admin.initialize_app(cred)
db = firestore.client()

@app.route('/api/profile/', methods=['GET'])
def get_profile(requested_user_id):
    auth_header = request.headers.get('Authorization')
    if not auth_header or not auth_header.startswith('Bearer '):
        return jsonify({'error': 'unauthorized'}), 401
    token = auth_header.split(' ')[1]
    try:
        # Verify the ID token and get the user's UID
        decoded_token = auth.verify_id_token(token)
        current_user_id = decoded_token['uid']
    except auth.InvalidIdTokenError:
        return jsonify({'error': 'invalid token'}), 401

    # Enforce access control: ensure the requested user matches the authenticated user
    if requested_user_id != current_user_id:
        return jsonify({'error': 'forbidden'}), 403

    doc = db.collection('users').document(requested_user_id).get()
    if doc.exists:
        return jsonify(doc.to_dict())
    return jsonify({'error': 'not found'}), 404

This pattern ensures that the resource identifier in the URL is validated against the authenticated principal, mitigating BOLA/IDOR. For Firestore-specific remediation, you can also store the user’s UID as a field within the document and re-check it on read/write, providing defense in depth:

@app.route('/api/data/', methods=['GET'])
def get_user_data(doc_id):
    auth_header = request.headers.get('Authorization')
    if not auth_header or not auth_header.startswith('Bearer '):
        return jsonify({'error': 'unauthorized'}), 401
    token = auth_header.split(' ')[1]
    try:
        decoded_token = auth.verify_id_token(token)
        current_user_id = decoded_token['uid']
    except auth.InvalidIdTokenError:
        return jsonify({'error': 'invalid token'}), 401

    # Fetch document and verify ownership field
    doc = db.collection('users').document(current_user_id).collection('data').document(doc_id).get()
    if doc.exists:
        # Optional: double-check a 'owner_uid' field matches current_user_id
        if doc.to_dict().get('owner_uid') == current_user_id:
            return jsonify(doc.to_dict())
        return jsonify({'error': 'forbidden'}), 403
    return jsonify({'error': 'not found'}), 404

These examples illustrate how to align Firestore data modeling with explicit authorization logic in Flask. By resolving identity server-side and scoping queries to the authenticated user’s path (e.g., users/{uid}/data/{doc_id}), you reduce the risk of IDOR. middleBrick’s Authentication and Property Authorization checks can help verify that such controls are present and correctly implemented in your API.