Beast Attack in Axum with Firestore

A Beast Attack (Binding Extra, Altered, or Swapped) in an Axum API that uses Google Cloud Firestore can occur when application logic does not validate or re-verify authorization for each individual resource access. Axum is a Rust web framework; if route parameters or query values are used to construct Firestore document paths without confirming the requesting user’s permissions, an attacker can swap identifiers to access another user’s data.

Consider an endpoint like /users/{user_id}/profile. If the handler retrieves the Firestore document using only the user_id from the URL and does not compare it to the authenticated subject’s ID, a BOLA/IDOR condition exists. Firestore security rules can help, but they are not a substitute for explicit server-side authorization checks within the application. Rules may be misconfigured or bypassed if the request context is not correctly enforced. For example, a rule that allows read access based on request.auth.uid == user_id can still be exploited if the application layer does not enforce the same check before forming the document reference.

In a real-world scenario, an attacker could iterate over numeric or predictable IDs, sending requests to GET /users/123/profile, GET /users/124/profile, and so on. If Axum passes these IDs directly to Firestore without verifying ownership, the attacker can read or modify profiles belonging to other users. This becomes more dangerous when Firestore documents contain sensitive fields such as email, role flags, or session tokens. The attack surface is amplified if Firestore documents include references to administrative operations or if the application uses Firestore listeners that expose change feeds without proper access checks.

Because Firestore is a NoSQL database, document paths are often constructed by concatenating user-controlled input. If Axum routes use path parameters to assemble these paths without strict validation, the risk of record swapping increases. For instance, using a string format like format!("users/{}", user_id) to build a document ID is acceptable only when the caller’s identity has already been verified. Without middleware or explicit checks that bind the authenticated subject to the provided identifier, the API effectively trusts the client-supplied ID, enabling a Beast Attack.

middleBrick detects this class of issue by correlating OpenAPI path parameters with runtime access patterns and Firestore interaction traces. Even without authentication, the scanner can identify endpoints that accept user-controlled identifiers and interact with Firestore resources. The report highlights whether findings align with OWASP API Top 10 A01:2023 broken object-level authorization and provides remediation guidance focused on server-side authorization and context-aware data access.

To prevent Beast Attacks in Axum when using Firestore, always resolve the authenticated subject on the server and use it to construct and validate Firestore document references before any read or write operation. Do not rely solely on Firestore security rules or client-supplied identifiers.

Below is a minimal Axum handler that demonstrates a safe pattern. It extracts the user ID from a JWT claim, builds the Firestore document path using that trusted subject, and ensures the requested path matches the authorized subject. The example uses the google-cloud-rust Firestore client and jsonwebtoken for authentication.

use axum::{routing::get, Router};
use google_cloud_firestore::client::Client;
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use serde::{Deserialize, Serialize};
use std::net::SocketAddr;

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    exp: usize,
}

async fn profile_handler(
    axum::extract::Path(requested_id): axum::extract::Path,
    firestore_client: &Client,
) -> Result<impl axum::response::IntoResponse, (axum::http::StatusCode, String)> {
    // In practice, the token would be extracted from the Authorization header
    let token = "HEADER_TOKEN_PLACEHOLDER";
    let decoding_key = DecodingKey::from_secret("YOUR_SECRET".as_ref());
    let validation = Validation::new(Algorithm::HS256);
    let token_data = decode::<Claims>(token, &decoding_key, &validation)
        .map_err(|_| (axum::http::StatusCode::UNAUTHORIZED, "Invalid token"))?;

    // Trusted subject from the token, not from the path
    let subject_id = token_data.claims.sub;

    // Ensure the requested ID matches the authenticated subject
    if requested_id != subject_id {
        return Err((axum::http::StatusCode::FORBIDDEN, "Access denied".to_string()));
    }

    // Build the Firestore document reference using the trusted subject
    let doc_ref = firestore_client
        .doc(&format!("users/{}/profile", subject_id))
        .get()
        .await
        .map_err(|e| (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    let profile: serde_json::Value = doc_ref.get(&firestore_client).await
        .map_err(|e| (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    Ok(axum::Json(profile))
}

#[tokio::main]
async fn main() {
    let client = Client::new().await.expect("Failed to create Firestore client");
    let app = Router::new()
        .route("/users/:user_id/profile", get(profile_handler));

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

This pattern ensures that the Firestore document path is derived from the server-side subject rather than the client-controlled parameter. Even if an attacker changes the URL path, the handler will reject the request unless the token’s subject matches. For additional protection, apply Firestore rules that mirror this ownership check, but do not rely on them as the sole defense.

In a microservice architecture where multiple Axum services access Firestore, centralize authorization logic into shared libraries or middleware. This reduces the risk of inconsistent checks across endpoints. middleBrick’s scans can validate whether Firestore interactions are preceded by proper identity binding and whether the API surface exposes endpoints that accept identifiers without corresponding authorization checks.