Race Condition in Axum with Firestore

A race condition in an Axum application using Firestore arises when multiple concurrent requests read and write shared document state without effective synchronization, leading to lost updates or inconsistent reads. Firestore provides multi-version concurrency control (MVCC) and transactional guarantees, but these must be used correctly in an async Rust service to avoid interleaved operations. In Axum, handlers are typically async and may execute concurrently for the same document (e.g., a counter or inventory record), creating a window where two requests read the same value, compute a new value, and write back, with the second write overwriting the first.

Consider a naive increment endpoint that reads a document, increments a numeric field, and writes it back. If two requests perform this sequence in parallel, both may read value 5, compute 6, and write 6, resulting in a lost increment. This occurs because the read and write are separate operations and not atomic. Firestore transactions or batched writes with preconditions (e.g., using update_time or a version field) are required to ensure atomicity. Without them, the application is vulnerable to race conditions that can corrupt state and violate invariants.

Additionally, Firestore’s document-level concurrency means that writes to the same document are serialized server-side, but the client-side logic in Axum does not inherently enforce ordering. If an Axum handler issues a get followed by a conditional update without a transaction, the condition may pass for both requests based on the state each saw locally, leading to unintended behavior. This is especially problematic when using optimistic concurrency via version numbers that are not validated atomically on write. Attackers can trigger high concurrency to increase the likelihood of race conditions, potentially causing data corruption or privilege escalation in workflows where state determines permissions.

The risk is compounded when Firestore security rules are used for authorization without considering concurrency. Rules are evaluated at write time against the current server state, but if the application logic relies on stale reads within the same request, it may incorrectly allow an operation that should be denied under the latest state. For example, a rule that checks a remaining quota may pass because the handler read an outdated value, but the write would exceed quota. Proper use of transactions or atomic field transforms (e.g., increment) mitigates this by ensuring the check and update occur atomically on the server.

In the context of API security scanning, race conditions are challenging to detect because they depend on timing and concurrency. middleBrick tests authentication, BOLA/IDOR, and property authorization across concurrent scenarios, but developers must design handlers to use Firestore’s atomic constructs. Relying on application-level sequencing or simple reads/writes without transactions leaves the API susceptible to subtle data integrity issues that may not be evident in low-concurrency testing but can be exploited under load.

To remediate race conditions in Axum with Firestore, use Firestore transactions or atomic operations to ensure that read-modify-write sequences are performed atomically. The Firestore Rust SDK supports transactions via Transaction and server-side atomic transforms such as Increment. Below are concrete, working examples that demonstrate safe patterns.

Using a Transaction for Atomic Increment

This pattern ensures that the read and write are executed atomically. The transaction retries automatically on conflict, providing strong consistency for the operation.

use firestore::FirestoreDb; // Assume FirestoreDb is initialized
use axum::extract::State;
use std::sync::Arc;

async fn increment_counter_handler(
    State(db): State>,
) -> Result<impl IntoResponse, (StatusCode, String)> {
    let transaction = db.start_transaction();
    let doc_ref = db.doc("counters/my_counter");
    
    // Transactional read and update
    let new_value: i64 = transaction.run(|tx| async move {
        let snapshot = tx.get(&doc_ref).await.map_err(|e| e.to_string())?;
        let current: i64 = snapshot.get("value").unwrap_or(0);
        tx.update(&doc_ref, &[("value", (current + 1).into())]).map_err(|e| e.to_string())?;
        Ok(current + 1)
    }).await.map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e))?;

    Ok(Json(json!({ "new_value": new_value })))
}

Using Atomic Increment Field Transform

For simple numeric updates, Firestore’s built-in increment transform is more efficient and avoids explicit transactions. This is the preferred approach for counters and aggregates.

use firestore::FirestoreDb;
use axum::extract::State;
use std::sync::Arc;

async fn increment_atomic_handler(
    State(db): State>,
) -> Result<impl IntoResponse, (StatusCode, String)> {
    let doc_ref = db.doc("counters/my_counter");
    db.increment(&doc_ref, "value", 1)
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    // Optionally read the updated value
    let snapshot = db.get(&doc_ref).await.map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    let new_value: i64 = snapshot.get("value").unwrap_or(0);

    Ok(Json(json!({ "new_value": new_value })))
}

Conditional Update Using Update Time or Version

When business rules require checking a condition before updating, use a document’s update time or a version field with a transaction to ensure the document has not changed since read.

use firestore::{FirestoreDb, Timestamp};
use axum::extract::State;
use std::sync::Arc;

async fn conditional_update_handler(
    State(db): State>,
    Json(payload): Json<UpdatePayload>,
) -> Result<impl IntoResponse, (StatusCode, String)> {
    let doc_ref = db.doc("items/item_123");
    let transaction = db.start_transaction();
    
    let result = transaction.run(|tx| async move {
        let snapshot = tx.get(&doc_ref).await.map_err(|e| e.to_string())?;
        let last_update: Timestamp = snapshot.get("updated_at").unwrap_or_default();
        
        if last_update >= payload.expected_update_time {
            return Err("Document has been modified since read".into());
        }
        
        tx.update(&doc_ref, &[("data", payload.data.clone().into())])
            .map_err(|e| e.to_string())?;
        Ok(())
    }).await;

    match result {
        Ok(_) => Ok(Json(json!({ "status": "updated" }))),
        Err(e) => Err((StatusCode::CONFLICT, e)),
    }
}

These patterns ensure that concurrent operations on Firestore documents from Axum handlers are safe and consistent. For API security, using these constructs reduces the risk of data corruption and authorization bypass due to race conditions. middleBrick’s scans can help identify endpoints where such unsafe patterns may exist by analyzing authorization flows and concurrent request handling.