Pii Leakage in Flask with Firestore

Pii Leakage occurs when personally identifiable information is exposed through an API or application layer. In a Flask application that uses Google Cloud Firestore as a database, the risk arises from improper data handling, overly permissive Firestore rules, and insufficient runtime validation. Flask routes that retrieve documents from Firestore can inadvertently return sensitive fields such as email addresses, phone numbers, government IDs, or location data if the application does not explicitly limit which fields are shared.

When Firestore documents contain nested objects or arrays, a common mistake is to return the entire document snapshot without filtering. For example, a user profile document might include a subcollection or fields like ssn, password_hash, or internal_notes. If the Flask route serializes the full document to the client, these fields become exposed. This is especially risky when Firestore security rules are misconfigured to allow read access based only on authentication status, without enforcing field-level restrictions.

The combination of Flask’s flexibility and Firestore’s document-oriented model increases the attack surface. Flask endpoints that construct Firestore queries using client-supplied parameters can be vulnerable to Insecure Direct Object References (IDOR) or Broken Function Level Authorization (BFLA), allowing an attacker to request other users’ documents. If those documents contain PII and the response is not filtered, the data is leaked. Additionally, Firestore’s support for nested maps and repeated fields can unintentionally expose related sensitive data if the application does not explicitly project or sanitize the query results.

Another scenario involves logging or error handling in Flask. If Firestore exceptions or debug information are returned in error responses, they may contain references to collections, document IDs, or metadata that help an attacker map the data store. Without proper input validation and output sanitization, even a standard GET endpoint can become a PII leakage vector.

To detect these risks, middleBrick scans the unauthenticated attack surface of a Flask + Firestore API, checking for missing field-level controls, overly permissive rules reflected in runtime behavior, and insecure data exposure patterns. Findings include severity ratings and remediation guidance mapped to frameworks such as OWASP API Top 10 and GDPR, helping teams understand and reduce exposure of sensitive information.

Remediation focuses on strict data modeling, query filtering, and secure serialization. In Flask, you should never return raw Firestore documents. Instead, explicitly select only the fields required by the client and validate all inputs used to construct queries.

First, structure your Firestore documents to separate sensitive data from public data. For example, store PII in a subcollection or a nested map that is not routinely returned, and restrict access using Firestore rules. Then, in your Flask route, use projection to limit returned fields.

from google.cloud import firestore
from flask import Flask, jsonify, request

app = Flask(__name__)
db = firestore.Client()

@app.route("/api/users/<user_id>", methods=["GET"])
def get_user_public(user_id):
    doc_ref = db.collection("users").document(user_id)
    doc = doc_ref.get()
    if not doc.exists:
        return jsonify({"error": "not found"}), 404
    # Explicitly select safe fields only
    safe_data = {
        "user_id": doc.id,
        "display_name": doc.get("display_name"),
        "avatar_url": doc.get("avatar_url"),
        "country": doc.get("country"),
    }
    return jsonify(safe_data)

This pattern ensures that even if the Firestore document contains fields like email, phone, or password_hash, they are not included in the HTTP response. You should also validate user_id to prevent IDOR, for example by checking that the requesting user is allowed to view this resource.

For routes that list collections, avoid returning full documents. Use aggregation or restricted queries, and apply field selection consistently:

@app.route("/api/users", methods=["GET"])
def list_users():
    # Limit the number of results and select only public fields
    docs = db.collection("users")
    # Optional: add role-based filters or tenant checks here
    results = docs.limit(50).stream()
    users = []
    for doc in results:
        users.append({
            "user_id": doc.id,
            "display_name": doc.get("display_name"),
            "country": doc.get("country"),
        })
    return jsonify(users)

In Firestore, you can also use select semantics by reading only specific fields via the client library if supported, or by restructuring documents so sensitive data lives in a separate document that requires additional authorization to read. Combine this with Flask middleware that scrubs logs and ensures error messages do not expose Firestore paths or internal identifiers.

middleBrick’s scans validate these patterns by comparing runtime responses against the OpenAPI specification and Firestore-aware checks, highlighting endpoints that return unfiltered or excessive data. The tool provides prioritized findings with severity levels and remediation guidance, helping teams implement secure data handling without relying on automatic fixes.