Broken Access Control in Axum with Firestore

Broken Access Control in an Axum service that uses Firestore typically arises when route-level authorization is missing or inconsistently applied and when Firestore security rules do not enforce user-specific constraints. Axum routes are composable and rely on explicit extractors and guards; if a handler assumes a user is authenticated and authorized without verifying permissions, it can expose data or operations to attackers.

Consider an endpoint that accepts a user ID path parameter to fetch or modify a document. If the handler retrieves the document directly using the provided ID without confirming that the authenticated subject matches that ID, this is a classic BOLA/IDOR pattern. Firestore rules that allow read or write access based only on document ID or that grant broad access to authenticated users can compound the issue. For example, a rule like allow read: if request.auth != null; permits any authenticated user to read any document, which may include other users’ data when the application does not enforce ownership checks in the handler.

In Axum, this often manifests when developers wire routes with shared state such as a Firestore client and use permissive matching like Router::new().route("/users/:user_id", get(get_user)) without validating that the extracted user_id aligns with the authenticated principal. An attacker can modify the path parameter to access or influence another user’s document. Firestore’s flexible query capabilities can also enable unintended access if rules allow collection group reads without scoping to user-specific fields.

Additionally, insufficient validation of incoming data can lead to privilege escalation when combined with Firestore’s field-level updates. If an Axum handler applies partial updates from request payloads directly to a Firestore document without verifying which fields may be changed by the user, an attacker might modify administrative flags or role attributes. Firestore rules that permit updates on specific paths may still allow writes to sensitive fields when the handler does not enforce a strict allowlist of updatable properties.

These interactions highlight why both application logic and Firestore rules must align: Axum must enforce authorization checks using typed extractors and policy evaluation, and Firestore rules must scope access to user-specific document segments, validate request methods, and constrain field-level mutations. Relying on only one layer increases the risk of exposure and can lead to sensitive data leakage or unauthorized operations.

To mitigate Broken Access Control in Axum with Firestore, enforce explicit ownership checks in handlers and tighten Firestore security rules. Below are concrete, realistic examples that demonstrate a secure pattern.

First, ensure your Axum route validates the authenticated user against the requested resource. Use an extractor that provides the subject’s user ID and compare it with the path parameter before constructing a Firestore document reference.

use axum::{routing::get, Router};
use firebase_rs::{Firebase, FirebaseValue};
use std::sync::Arc;

struct AuthUser {
    user_id: String,
}

async fn get_user_profile(
    AuthUser { user_id }: AuthUser,
    Path(requested_id): Path,
    firebase: Extension>,
) -> Result {
    // Enforce ownership: do not proceed if IDs differ
    if user_id != requested_id {
        return Err((StatusCode::FORBIDDEN, "Access denied".to_string()));
    }
    let doc = firebase.at(&format!("users/{}", requested_id)).get().map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    let profile: UserProfile = doc.get().map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    Ok(Json(profile))
}

Second, tighten Firestore rules to scope access to each user’s own document. Use request.auth.uid to constrain reads and writes, and avoid broad allow statements.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Third, prevent privilege escalation by validating which fields can be updated. In Axum, parse the incoming patch payload against an allowlist and apply changes only to permitted fields before calling Firestore update.

use serde_json::Value;

async fn update_user_settings(
    AuthUser { user_id }: AuthUser,
    Path(requested_id): Path,
    firebase: Extension>,
    Json(payload): Json,
) -> Result {
    if user_id != requested_id {
        return Err((StatusCode::FORBIDDEN, "Access denied".to_string()));
    }
    // Allowlist of user-editable fields
    let allowed = ["theme", "language", "notifications_enabled"];
    for key in payload.as_object().unwrap().keys() {
        if !allowed.contains(&key.as_str()) {
            return Err((StatusCode::BAD_REQUEST, format!("Field not allowed: {}", key)));
        }
    }
    firebase.at(&format!("users/{}", requested_id)).update(payload.to_string()).map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    Ok(StatusCode::NO_CONTENT)
}

These steps align application controls with Firestore’s rule-based model: the handler verifies ownership and field-level permissions, while the rules provide a last line of defense by binding access to authenticated user identifiers and limiting mutation scope. This combination reduces the likelihood of IDOR and privilege escalation when using Axum and Firestore together.