Insecure Design in Axum with Firestore

Insecure design in an Axum application that uses Google Cloud Firestore often arises from modeling data and access patterns that do not enforce least-privilege and ownership at the database layer. Firestore’s flexible document model can encourage storing user data in flat collections without strict ownership checks, which becomes dangerous when Axum routes assume the requesting user is allowed to read or modify any document whose ID they know.

For example, a route like /users/{user_id}/profile might retrieve a document with ID equal to user_id from a profiles collection. If the handler does not verify that the authenticated subject matches the document ID, an authenticated user can enumerate or modify any profile by guessing or iterating IDs. This is a classic BOLA (Broken Level of Access) pattern that insecure design permits: trusting path parameters instead of validating ownership against the authoritative identity store.

Firestore exacerbates this when security rules are permissive for reads/writes (e.g., allowing read access to all documents in a collection) and the application layer does not re-enforce boundaries. An attacker can leverage valid authentication tokens to issue requests that reach Firestore because Axum does not gate access by resource ownership or role. Additionally, Firestore’s support for nested maps and arrays can lead to over-fetching if queries retrieve entire documents when only a few fields are needed, increasing the data exposure surface in case of an insecure design that does not limit returned fields.

Another insecure design pattern is embedding sensitive metadata (such as roles or admin flags) within documents that should be verified server-side. If an Axum handler relies on client-supplied role claims without cross-checking Firestore-stored roles, privilege escalation becomes feasible. Similarly, unbounded queries that allow clients to specify filters (e.g., a search endpoint that passes user input directly to Firestore) can lead to excessive data retrieval or enumeration if the design does not enforce strict query constraints and pagination.

These issues map to OWASP API Top 10 controls such as broken access control and excessive data exposure. Because Firestore is a managed NoSQL store, developers must design Axum handlers to treat every document read or write as a privilege-checked operation, not a simple key-value fetch. Without server-side ownership validation and strict rule scoping, the combination of Axum’s routing flexibility and Firestore’s permissive defaults creates an insecure design that exposes unauthorized access paths.

Remediation centers on enforcing ownership checks, scoping Firestore queries, and avoiding trust in client-supplied identifiers. In Axum, extract the authenticated principal from request extensions or JWT claims, and use it to constrain every Firestore operation. Below is a secure handler pattern that binds the user ID from authentication to the Firestore document ID.

// Axum handler with Firestore ownership check
use axum::{routing::get, Router, extract::State, http::StatusCode};
use google_firestore1::FirestoreDb;
use serde::Deserialize;

#[derive(Deserialize)]
struct PathUserId(String);

async fn get_profile(
    State(db): State,
    Path(user_id): Path,
    // Assume auth extractor provides the authenticated subject ID
    auth_subject: AuthSubject,
) -> Result {
    // Enforce ownership: subject must match path user_id
    if auth_subject.user_id != user_id {
        return Err((StatusCode::FORBIDDEN, "Unauthorized".into()));
    }

    let doc_path = format!("profiles/{}", user_id);
    let doc = db.doc(&doc_path).get().await.map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    if !doc.exists() {
        return Err((StatusCode::NOT_FOUND, "Profile not found".into()));
    }

    // Select only required fields to reduce data exposure
    let data = doc.get_fields_to_map(&["display_name", "email"]);
    Ok(serde_json::to_string(&data).unwrap_or_default())
}

In this example, auth_subject.user_id is derived from a verified token (e.g., via JWT validation middleware) and is not taken from the request path alone. The Firestore document path is constructed from the validated subject, ensuring that users cannot read or write arbitrary documents. Field selection via get_fields_to_map limits returned data, addressing excessive data exposure in insecure designs that might otherwise return entire documents.

For queries that involve collections (e.g., user-owned records), scope the query by the authenticated subject and avoid passing unsanitized client filters directly to Firestore. The following pattern demonstrates a secure query design:

// Secure query scoped to authenticated user
async fn list_user_items(
    State(db): State,
    auth_subject: AuthSubject,
) -> Result, (StatusCode, String)> {
    let col = db.collection("items")
        .where_filter("owner_id", "==", auth_subject.user_id)
        .limit(50);

    let snapshot = col.get().await.map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    let items: Vec = snapshot.documents().map(|doc| doc.deserialize()).collect::>()
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    Ok(items)
}

This query ensures that Firestore only returns documents where owner_id matches the authenticated user, implementing server-side access control that compensates for any permissive security rules. It also enforces a limit to prevent excessive data retrieval, which insecure designs might allow via unbounded queries.

Remediation also involves reviewing Firestore security rules to ensure they align with least privilege, but the primary fix in Axum is to make ownership and role checks mandatory in handlers and to avoid exposing internal IDs or roles to the client. Combine this with runtime scanning tools such as the middleBrick CLI to detect insecure design patterns in your API surface; for example, you can run middlebrick scan <url> to identify BOLA and data exposure findings. Teams using CI/CD can integrate the middleBrick GitHub Action to fail builds when risk scores drop below a chosen threshold, while the Pro plan’s continuous monitoring can alert on regressions. For deeper IDE integration during development, the MCP Server lets you scan APIs directly from editors used by security-aware developers.