Nosql Injection in Flask with Firestore

Nosql Injection occurs when user-controlled input is interpreted as part of a database query rather than purely as data. In a Flask application using Google Cloud Firestore, this typically arises when query filters, field selectors, or key paths are constructed by concatenating or interpolating request parameters into Firestore calls. Because Firestore’s API accepts dictionaries and structured objects that are interpreted as query constraints, malicious input can change the semantics of the query, bypass intended filters, or read unintended documents.

Consider a Flask route that retrieves a user profile by user ID passed as a URL parameter:

@app.route('/profile')
def get_profile():
    user_id = request.args.get('user_id')
    doc_ref = db.collection('users').document(user_id)
    snapshot = doc_ref.get()
    return {'user_id': user_id, 'data': snapshot.to_dict()}

If user_id is not validated and an attacker supplies a value like admin' OR '1'=='1 or uses dot notation to traverse collections (e.g., ../../../config), Firestore may treat path segments as separate keys, potentially reading documents outside the intended scope. Firestore does not have a traditional query language, but its structured query model allows compound filters and field lookups; if input is used to build field filters unsafely, an attacker can supply values that change which documents are returned.

Another common pattern is using input to specify which fields to return or which collection to target:

@app.route('/users')
def list_users():
    field = request.args.get('field', 'email')
    docs = db.collection('users').select(field).stream()
    return [{'field': field, 'value': getattr(doc.to_dict(), field, None)} for doc in docs]

An attacker can set field to something like email,admin_privileges or use dot traversal to reference sensitive top-level keys, effectively exfiltrating data that the application logic did not intend to expose. Because Firestore’s select accepts a variable number of field paths, unsanitized input can widen the data exposure beyond the expected subset.

The risk is compounded when Firestore rules are misconfigured or assumed to fully mitigate injection; rules operate on the request context and can be bypassed if the client-supplied document path or field list allows access to unintended resources. Attack patterns include unauthorized data reading, privilege escalation via role fields, and enumeration of collections through error differences. Unlike SQL injection, NoSQL injection does not always produce errors; instead it silently returns broader data, making detection harder without runtime security checks.

Remediation focuses on strict input validation, avoiding dynamic construction of document paths or field lists, and using Firestore’s built-in safeguards. Always treat user input as opaque identifiers, never as structural query components.

Validate and normalize identifiers: Ensure document IDs conform to an expected pattern and do not contain path traversal characters. Use allowlists where possible.

import re
from flask import request, jsonify

def is_valid_user_id(user_id: str) -> bool:
    # Allow only alphanumeric, underscore, dash, and up to 32 chars
    return bool(re.fullmatch(r'[A-Za-z0-9_-]{1,32}', user_id))

@app.route('/profile')
def get_profile_safe():
    user_id = request.args.get('user_id')
    if not is_valid_user_id(user_id):
        return jsonify({'error': 'invalid user_id'}), 400
    doc_ref = db.collection('users').document(user_id)
    snapshot = doc_ref.get()
    if not snapshot.exists:
        return jsonify({'error': 'not found'}), 404
    return jsonify({'user_id': user_id, 'data': snapshot.to_dict()})

Use whitelists for field selection: Do not pass raw field names from request parameters into select. Instead, map allowed fields to known safe values.

ALLOWED_FIELDS = {'email', 'display_name', 'photo_url'}

@app.route('/users')
def list_users_safe():
    field = request.args.get('field', 'email')
    if field not in ALLOWED_FIELDS:
        return jsonify({'error': 'field not allowed'}), 400
    docs = db.collection('users').select(field).stream()
    return jsonify([{'user_id': doc.id, field: doc.get(field)} for doc in docs])

Avoid dynamic collection names and paths: If you must support multi-tenant or scoped data, validate the scope against a fixed set rather than concatenating strings.

VALID_SCOPES = {'public', 'team', 'org'}

@app.route('/data')
def get_scoped_data():
    scope = request.args.get('scope', 'public')
    if scope not in VALID_SCOPES:
        return jsonify({'error': 'invalid scope'}), 400
    collection_name = f'{scope}_data'
    # Ensure collection_name is still validated; prefer a mapping
    allowed_map = {'public': 'public_data', 'team': 'team_data', 'org': 'org_data'}
    collection_name = allowed_map[scope]
    docs = db.collection(collection_name).limit(100).stream()
    return jsonify([doc.to_dict() for doc in docs])

Leverage Firestore rules as a safety net, not the primary defense: Rules should enforce authentication and ownership, but they cannot compensate for application-level logic that exposes unintended paths. Design rules to be restrictive and test them independently.

By combining strict allowlists, input normalization, and avoiding dynamic query assembly, you reduce the attack surface for Nosql Injection in Flask applications using Firestore. The middleBrick scanner can detect exposed endpoints and unsafe query patterns; the Pro plan supports continuous monitoring so changes in API behavior can be flagged promptly.