Integer Overflow in Axum with Firestore

An integer overflow in an Axum handler that interacts with Firestore can occur when user-supplied numeric values (e.g., quantity, batch size, or array indices) are used to compute Firestore document paths, page sizes, or limits without range validation. Axum extracts values such as IDs or counters from path or query parameters as integers; if these values are not bounded, arithmetic operations like multiplication or addition may wrap around, producing unexpected small values or large values that bypass intended checks.

Because Firestore document IDs and numeric fields are often used directly in lookups, an overflowed value can lead to incorrect document references, privilege escalation via IDOR (e.g., reading or writing another user’s document), or bypass of rate-limiting logic. For example, a crafted large integer that overflows to zero may cause the application to read or write a shared document instead of a per-user document. The Firestore SDK does not prevent integer overflow in client-supplied values; it trusts the values passed in paths or query parameters, so validation must happen in Axum before any Firestore interaction.

In the context of middleBrick’s 12 security checks, BOLA/IDOR and Input Validation tests would flag unbounded numeric inputs that feed Firestore queries or document paths. The scanner does not fix the issue but provides prioritized findings with severity and remediation guidance, highlighting the need to validate and sanitize integers before using them in Firestore operations.

Remediation focuses on validating and sanitizing integers before they are used in Firestore paths, queries, or limits. Use strict parsing, range checks, and rejection of values that could overflow or underflow. Prefer using i64 for intermediate calculations and enforce business-specific boundaries. Below are concrete Axum handler examples with Firestore integration using the official Firestore SDK for Rust.

• Validate numeric input with explicit bounds and reject suspicious values before constructing Firestore document paths.
• Use checked arithmetic (checked_add, checked_mul) to detect overflow/underflow and return a 400 response if detected.
• For limits used in queries (e.g., page size), enforce a reasonable maximum to prevent resource exhaustion or unintended broad queries.

use axum::{routing::get, Router};
use firestore::FirestoreDb;
use serde::Deserialize;
use std::net::SocketAddr;

#[derive(Deserialize)]
struct ListItemsQuery {
    user_id: String,
    limit: Option,
}

async fn list_items(
    user_id: String,
    query: axum::extract::Query,
    db: axum::extract::State<FirestoreDb>
) -> Result<impl IntoResponse, (axum::http::StatusCode, String)> {
    // Validate limit with a safe maximum to prevent abuse
    const MAX_LIMIT: i64 = 100;
    let limit = match query.limit {
        Some(v) if v > 0 && v <= MAX_LIMIT => v,
        Some(_) => return Err((axum::http::StatusCode::BAD_REQUEST, "limit out of range".into())),
        None => MAX_LIMIT,
    };

    // Use checked arithmetic when computing offsets or derived values
    let offset: i64 = 0; // could come from pagination token
    let safe_offset = offset.checked_add(0).ok_or_else(|| {
        (axum::http::StatusCode::BAD_REQUEST, "invalid pagination parameter".into())
    })?;

    // Build document path safely; ensure user_id is validated separately
    let doc_path = format!("users/{}/items", user_id);
    let items: Vec<serde_json::Value> = db
        .collection("items")
        .with_limit(limit as usize)
        .get_documents()
        .await
        .map_err(|e| (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    Ok(axum::Json(items))
}

#[tokio::main]
async fn main() {
    let db = FirestoreDb::new("my-project-id").expect("Firestore init");
    let app = Router::new()
        .route("/users/:user_id/items", get(list_items))
        .with_state(db);

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

For scenarios where numeric IDs come from path parameters, enforce strict whitelisting or use UUIDs instead of sequential integers to reduce IDOR risk. When computing derived values (e.g., totals, aggregates), prefer server-side computations inside Firestore (e.g., via Cloud Functions) or validate ranges on the Rust side before sending to Firestore. middleBrick’s CLI can be used to scan Axum endpoints for such input validation issues by running middlebrick scan <url> and reviewing the Input Validation and BOLA/IDOR findings.