Integrity Failures in Actix with Firestore

Integrity failures occur when an API allows unauthorized modification, deletion, or corruption of data. When an Actix web service interacts with Google Cloud Firestore without strict ownership and validation checks, the API surface can expose endpoints that let one user alter or overwrite another user’s documents. This typically maps to the BOLA/IDOR category in middleBrick’s checks, where insecure direct object references allow attackers to iterate through predictable Firestore document IDs and tamper with records.

Consider a naive Actix handler that retrieves a document using a user-supplied ID and applies a partial update without confirming that the authenticated user owns that document:

async fn update_settings(req: HttpRequest, body: web::Json<SettingsUpdate>) -> Result<impl Responder, Error> {
    let doc_id = req.match_info().get("doc_id").unwrap_or_default();
    let db = FirestoreDb::new("my-project").await?;
    let doc_ref = db.collection("user_settings").doc(doc_id);
    // Missing: verify that doc_id belongs to the requesting user
    doc_ref.update(&body.into_inner().to_firestore_fields()).await?;
    Ok(HttpResponse::Ok().finish())
}

In this pattern, the doc_id is taken directly from the route. An attacker can change the ID to reference another user’s settings document. Because Firestore enforces authentication at the connection level but not at the document level by default, the request may succeed if the service account used by Actix has broad read/write permissions. middleBrick’s BOLA checks would flag this by submitting modified document IDs and observing whether the API enforces ownership, returning a high-severity finding when tampering is possible.

Integrity issues are compounded when Firestore security rules are misconfigured or omitted in development. If the rules rely only on request.auth != null without scoping writes to user-specific paths, the API allows cross-user writes. middleBrick’s OpenAPI/Swagger analysis can detect insecure rule patterns by correlating spec definitions with runtime behavior, such as endpoints that accept user-controlled identifiers without path or claim validation.

Another scenario involves optimistic concurrency without versioning. Firestore supports transactions and precondition checks, but if an Actix endpoint applies updates without reading the existing document’s version or timestamp, concurrent requests can overwrite each other’s changes:

async fn increment_counter(req: HttpRequest) -> Result<impl Responder, Error> {
    let doc_id = req.match_info().get("counter_id").unwrap_or_default();
    let db = FirestoreDb::new("my-project").await?;
    let col = db.collection("counters");
    let doc_ref = col.doc(doc_id);
    // No transaction or update_mask; race condition allows lost updates
    let snap = doc_ref.get().await?;
    let current: i64 = snap.get("value").unwrap_or(0);
    doc_ref.set(json!({ "value": current + 1 })).await?;
    Ok(HttpResponse::Ok().finish())
}

Here, two simultaneous requests can read the same current value and write back an incremented value, causing one increment to be lost. This integrity violation is detectable by middleBrick’s tests for BFLA/privilege escalation and property authorization when the API lacks per-request uniqueness or locking mechanisms.

Data exposure can also relate to integrity when read paths do not validate input strictly, allowing type confusion or injection that leads to unintended writes. For example, deserializing Firestore documents into loosely typed structures may let an attacker supply numeric strings where booleans are expected, causing logic flaws in authorization decisions. middleBrick’s input validation checks look for such inconsistencies between spec definitions and runtime handling.

Finally, inventory management and unsafe consumption patterns in Actix can result in stale or duplicated state if Firestore writes are not idempotent. Without request IDs or deduplication logic, retries may apply the same mutation multiple times, corrupting data integrity. middleBrick’s checks for unsafe consumption highlight missing idempotency safeguards in API flows that interact with Firestore.

Remediation focuses on enforcing ownership, validating inputs, and using Firestore features correctly within Actix handlers. Always scope queries to the authenticated user and avoid trusting route parameters for document identity without verification.

First, bind the authenticated user’s UID to the document path. Instead of using a client-provided ID, derive the document reference from the request’s identity:

async fn update_settings_secure(
    req: HttpRequest,
    body: web::Json<SettingsUpdate>,
    user_id: web::ReqData<String>, // injected by Actix identity middleware
) -> Result<impl Responder, Error> {
    let db = FirestoreDb::new("my-project").await?;
    // Path is scoped to the authenticated user
    let doc_ref = db
        .collection("user_settings")
        .doc(user_id.into_inner())
        .collection("settings")
        .doc("app");
    doc_ref.update(&body.into_inner().to_firestore_fields()).await?;
    Ok(HttpResponse::Ok().finish())
}

By deriving the document ID from the authenticated user context rather than the route, you eliminate the BOLA vector. middleBrick’s authentication checks would verify that the endpoint properly restricts access compared to the unauthenticated attack surface.

Second, use Firestore transactions when applying read-modify-write sequences to preserve integrity under concurrency:

async fn increment_counter_safe(
    counter_id: web::Path<String>,
    db: web::Data<FirestoreDb>,
) -> Result<impl Responder, Error> {
    let counter_ref = db.collection("counters").doc(counter_id.into_inner());
    let _ = db.run_transaction(|transaction| async move {
        let snap = transaction.get(&counter_ref).await?;
        let current: i64 = snap.get("value").unwrap_or(0);
        transaction.set(&counter_ref, json!({ "value": current + 1 })).await?;
        Ok(()) as Result<_, Error>
    }).await?;
    Ok(HttpResponse::Ok().finish())
}

This pattern ensures that concurrent updates do not lose increments. Firestore transactions retry on conflict, maintaining consistency. middleBrick’s checks for property authorization and data exposure would validate that such safeguards exist.

Third, enforce strict input validation and type mapping. Define a strongly-typed structure for updates and reject fields that do not match the expected schema:

async fn validate_and_update(
    req: HttpRequest,
    payload: web::Json<serde_json::Value>,
) -> Result<impl Responder, Error> {
    let updates = payload.into_inner();
    // Ensure only allowed fields are present
    if updates.get("email").and_then(|v| v.as_str()).is_none() {
        return Err(ErrorBadRequest("email is required"));
    }
    // Proceed with scoped write as shown earlier
    Ok(HttpResponse::Accepted().finish())
}

Input validation prevents type confusion and reduces the attack surface for injection or malformed writes. middleBrick’s input validation checks confirm that the API rejects unexpected or malicious payloads.

Finally, leverage Firestore security rules in development to complement application-level controls. Even when testing with middleBrick’s unauthenticated scans, rules should limit writes to owner subcollections:

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

Combining Actix ownership scoping, transactions, strict validation, and properly scoped Firestore rules provides defense-in-depth against integrity failures. middleBrick’s scans can verify that these controls are present and that findings align with OWASP API Top 10 and compliance mappings.