Integrity Failures in Axum with Firestore

Integrity failures occur when an application does not enforce strong checks on data correctness and trustworthiness between components. When using the Rust web framework Axum with Google Cloud Firestore as the backend, integrity risks arise at the intersection of application logic, Firestore document models, and Firestore security rules. Firestore provides multi-region replication and strong consistency for reads within a region, but it does not automatically enforce semantic integrity constraints required by business logic.

In Axum, handlers typically deserialize HTTP payloads into structs, apply business rules, and then write data to Firestore using the Firestore REST or gRPC APIs via a client library. If Axum does not validate data against a strict schema and expected invariants before writing, or if Firestore rules are permissive (e.g., allowing writes based only on authentication presence without field-level validation), integrity violations can occur. For example, numeric fields such as account balances, version counters, or inventory quantities may be updated without checks for underflow, overflow, or race conditions. Firestore transactions help, but they must be correctly implemented in Axum to compare existing values and apply updates conditionally.

Another common pattern is using Firestore for document storage where Axum endpoints accept user-supplied identifiers to reference documents. Without strict ownership checks and canonical path construction, attackers can exploit insecure direct object references (IDOR) to modify documents they should not access. Firestore’s security rules can mitigate this when rigorously defined, but rules that rely only on request.auth.uid without verifying resource-level ownership expose integrity gaps. Additionally, Firestore’s flexible schema permits clients to inject unexpected or malformed fields; if Axum does not explicitly validate and sanitize these fields on read and write, the database can store invalid states that propagate through the system.

LLM/AI Security considerations also intersect with integrity when endpoints expose model outputs or prompts that include Firestore document content. If Axum routes include unchecked user input used to query Firestore and that content is later passed to an LLM endpoint, improperly sanitized data can contribute to prompt injection or output leakage. middleBrick’s LLM/AI Security checks specifically detect system prompt leakage and active prompt injection, which can be relevant when Axum services use Firestore-stored configuration or logs as context for AI features.

To detect such integrity issues, scanning an Axum + Firestore API with middleBrick runs checks across Input Validation, Property Authorization, BOLA/IDOR, and LLM/AI Security in parallel. The tool compares Firestore rules and runtime behavior against OWASP API Top 10 and compliance frameworks, highlighting missing constraints, overly permissive rules, and insufficient transaction usage without implying automatic fixes.

Remediation focuses on strict validation, secure Firestore rules, and safe transaction usage in Axum handlers. Always validate incoming data against a strong schema (for example using Serde with custom deserialization logic or a validation crate) before constructing Firestore documents. Enforce ownership by embedding user identifiers in document paths and verifying them in Firestore security rules, rather than relying solely on request-level authentication.

Example Axum handler with validation and Firestore transaction:

use axum::{
    extract::State,
    routing::post,
    Json, Router,
};
use firestore::*;
use serde::{Deserialize, Serialize};
use std::sync::Arc;

#[derive(Debug, Deserialize, Serialize)]
struct UpdateBalancePayload {
    account_id: String,
    delta_i64,
}

#[derive(Debug, Serialize)]
struct Account {
    balance_i64,
    version_u64,
}

async fn update_balance_handler(
    State(db): State>,
    Json(payload): Json,
) -> Result {
    // Validate on entry
    if payload.delta_i64 == 0 {
        return Err((StatusCode::BAD_REQUEST, "delta must be non-zero".to_string()));
    }
    if payload.account_id.is_empty() {
        return Err((StatusCode::BAD_REQUEST, "account_id required".to_string()));
    }

    let doc_path = format!("accounts/{}", payload.account_id);
    let transaction = db.transaction();

    // Read current document within transaction
    let current: Option = transaction
        .get(&doc_path)
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    let mut account = current.ok_or_else(|| {
        (StatusCode::NOT_FOUND, format!("Account {} not found", payload.account_id))
    })?;

    // Enforce business integrity: no negative balance
    let new_balance = account
        .balance_i64
        .checked_add(payload.delta_i64)
        .ok_or_else(|| (StatusCode::BAD_REQUEST, "balance overflow"))?;
    if new_balance < 0 {
        return Err((StatusCode::BAD_REQUEST, "balance cannot be negative".to_string()));
    }

    // Conditional update using transaction to prevent race conditions
    transaction.set(&doc_path, &Account {
        balance_i64: new_balance,
        version_u64: account.version_u64 + 1,
    });

    // Commit transaction; retry logic can be added for contention
    transaction
        .commit()
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    Ok(Json(serde_json::json!({
        "account_id": payload.account_id,
        "balance": new_balance,
        "version": account.version_u64 + 1,
    })))
}

Corresponding Firestore security rules should enforce ownership and constraints:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /accounts/{accountId} {
      allow read, write: if request.auth != null && request.auth.uid == accountId;
      // Additional field-level validation can be expressed using request.resource.data
      allow write: if request.resource.data.keys().hasAll(['balance_i64', 'version_u64'])
                  && request.resource.data.balance_i64 is int
                  && request.resource.data.version_u64 is int;
    }
  }
}

For LLM/AI Security, ensure that any Firestore-sourced context passed to an LLM endpoint is sanitized and that active prompt injection probes from middleBrick are considered during design. middleBrick’s scans can identify missing validation and permissive rules in Firestore-backed Axum services, and the Pro plan’s continuous monitoring can alert on rule changes that weaken integrity.