Cryptographic Failures in Fastapi with Firestore

Cryptographic failures occur when data is not adequately protected in transit or at rest. In a Fastapi application that uses Google Cloud Firestore as a backend, the combination of an API layer and a managed NoSQL database can introduce subtle risks if cryptographic controls are misconfigured or inconsistently applied.

One common scenario is when Fastapi endpoints accept sensitive fields (such as authentication tokens, personal identifiers, or encryption keys) and write them directly to Firestore without enforcing field-level encryption or deterministic encryption for searchable fields. Because Firestore stores data as JSON documents on Google infrastructure, unprotected values remain readable at rest unless explicitly encrypted before write operations. If the Fastapi service uses the Firestore client library with default settings and relies on Google-managed encryption, data is protected at rest by Google’s infrastructure encryption. However, this does not prevent exposure through the application layer: if an attacker compromises the runtime environment or gains unauthorized read access via an IDOR or BOLA flaw, they can retrieve plaintext sensitive fields directly from Firestore documents returned by the API.

Another risk arises from improper use of HTTPS between Fastapi and Firestore. The Firestore client library must use secure TLS connections. If custom HTTP clients or misconfigured transports bypass TLS verification, data in transit can be exposed to interception. Additionally, if Fastapi logs request or response payloads (for debugging or audit), sensitive data may be inadvertently persisted in logs, creating a cryptographic failure where secrets are stored in plaintext log stores.

Compliance mappings such as OWASP API Top 10 (2023) A02:2023 — Cryptographic Failures, PCI-DSS requirement 4 (encryption of cardholder data), and GDPR Article 32 (security of processing) highlight the importance of ensuring confidentiality and integrity. In this stack, a finding may be surfaced by middleBrick’s Data Exposure and Encryption checks when it detects responses containing API keys, PII, or when Firestore read/write operations do not demonstrate enforced encryption at the field level.

Consider an example where a Fastapi endpoint creates a user document in Firestore without encrypting the email address. An authenticated attacker exploiting BOLA could enumerate other user IDs and retrieve documents containing plaintext emails. middleBrick’s Property Authorization and BOLA/IDOR checks would correlate runtime access patterns with the Firestore schema to flag this as a high-severity data exposure finding, referencing the need for encryption before persistence.

Remediation focuses on ensuring sensitive data is encrypted before being stored in Firestore and that transport security is strictly enforced. Below are concrete code examples for a Fastapi service using the official Google Cloud Firestore client.

1. Use envelope encryption with a locally managed key to encrypt sensitive fields before writing to Firestore. This ensures that even if document-level access is obtained, values remain protected.

from fastapi import FastAPI, HTTPException
from google.cloud import firestore
from cryptography.fernet import Fernet
import os

app = Fastapi()

# Load or generate a deterministic data key; in production, use a KMS-backed approach
# For demonstration, we derive a Fernet key from an environment variable
key = os.environ.get("ENCRYPTION_KEY")
if not key:
    raise RuntimeError("ENCRYPTION_KEY environment variable is required")

cipher = Fernet(key)

def encrypt_field(value: str) -> str:
    return cipher.encrypt(value.encode()).decode()

def decrypt_field(value: str) -> str:
    return cipher.decrypt(value.encode()).decode()

@app.post("/users/{user_id}")
async def create_user(user_id: str, email: str, ssn: str):
    db = firestore.Client()
    doc_ref = db.collection("users").document(user_id)
    doc_ref.set({
        "email": encrypt_field(email),
        "ssn": encrypt_field(ssn),
        "created_at": firestore.SERVER_TIMESTAMP
    })
    return {"status": "created"}

@app.get("/users/{user_id}")
async def get_user(user_id: str):
    db = firestore.Client()
    doc = db.collection("users").document(user_id).get()
    if not doc.exists:
        raise HTTPException(status_code=404, detail="User not found")
    data = doc.to_dict()
    return {
        "user_id": user_id,
        "email": decrypt_field(data["email"]),
        "ssn": decrypt_field(data["ssn"])
    }

# Ensure default TLS settings are not overridden; rely on google.auth default credentials
from google.cloud import firestore

db = firestore.Client()  # Uses Application Default Credentials and HTTPS endpoints

from pydantic import BaseModel, validator
import re

class UserCreate(BaseModel):
    email: str
    ssn: str

    @validator("email")
    def email_must_be_encrypted_on_writes(cls, v):
        # In this workflow, the API layer encrypts before Firestore;
        # this validator ensures no accidental plaintext leaks in logs.
        if "@" in v and not v.startswith("enc:" ):
            # Application-level encryption is expected before persistence
            raise ValueError("email must be encrypted before storage")
        return v