Injection Flaws in Actix with Firestore

Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. In an Actix web service that uses Google Cloud Firestore as a backend, injection risks arise when request parameters, headers, or body contents are used to build Firestore queries, document paths, or field filters without proper validation or parameterization. Unlike SQL, Firestore does not support a traditional query language with string-based filters; however, constructing collection or document paths from user input or embedding user-controlled values into map keys or field names can lead to unintended data access, privilege escalation, or exposure of sensitive documents.

Actix is a powerful, actor-based framework for Rust that encourages asynchronous request handling. When handlers deserialize JSON into Rust structs and then forward values directly into Firestore operations, the risk is that malicious input can alter the intended scope of a read or write. For example, an attacker may supply a document ID such as users/../../../admin/settings if path segments are concatenated naively, potentially allowing access to documents outside the intended tenant or scope. Similarly, using user input to construct field names in update maps can lead to writes into system-reserved or sensitive fields, or enable attackers to pivot across logical partitions in the database.

Because Firestore rules rely on stable, predictable document paths and field structures, unpredictable or user-driven composition increases the probability of misconfigured security rules being bypassed. If the Actix service does not enforce strict allow-lists on identifiers and does not validate document ownership per request, an unauthenticated or low-privilege caller might leverage crafted input to enumerate collections or read documents that should be restricted. The combination of Actix’s flexibility in routing and Firestore’s hierarchical data model amplifies the impact of injection when input is not rigorously constrained.

In the context of middleBrick’s checks, this scenario is surfaced through the BOLA/IDOR and Input Validation security checks. The scanner tests whether document identifiers and query parameters can be manipulated to access unauthorized data, and whether input is sanitized before being used in Firestore operations. These tests do not assume any internal architecture, but they verify that the observable API behavior prevents unauthorized data exposure.

Defensive programming and strict input validation are essential when integrating Actix with Firestore. All user-supplied values that influence document paths, collection names, or field keys must be validated against an allow-list, and sensitive operations should be scoped to the requesting user’s tenant or identity.

Path validation and tenant scoping

Ensure that document IDs and collection names are not directly derived from raw input. Instead, use a fixed prefix or UUID-based identifier and associate data with the authenticated user’s tenant ID. The following example demonstrates safe document referencing in Actix using the Firestore Rust SDK:

use firestore::FirestoreDb; use actix_web::{web, HttpResponse};

async fn get_user_profile(db: web::Data<FirestoreDb>, path: web::Path<(String,)>, user_id: String) -> HttpResponse {
    let (input_id,) = path.into_inner();
    // Allow-list check: only alphanumeric IDs of length 16 are accepted
    if !input_id.chars().all(|c| c.is_ascii_alphanumeric()) || input_id.len() != 16 {
        return HttpResponse::BadRequest().body("Invalid document ID");
    }
    let doc_path = format!("tenants/{}/users/{}", user_id, input_id);
    match db.get_doc(&doc_path).await {
        Ok(doc) => HttpResponse::Ok().json(doc),
        Err(_) => HttpResponse::NotFound().finish(),
    }
}

Safe update maps and field names

When applying updates, avoid using raw keys from user input. Instead, map validated input to known field names and use Firestore’s update mechanisms with explicit field paths:

use firestore::FieldValue;
use std::collections::HashMap;

fn sanitize_update(updates: HashMap<String, FieldValue>, allowed_fields: &[&str]) -> Option<HashMap<String, FieldValue>> {
    let mut safe = HashMap::new();
    for (k, v) in updates {
        if allowed_fields.contains(&k.as_str()) {
            safe.insert(k, v);
        }
    }
    if safe.is_empty() { None } else { Some(safe) }
}

// Usage: only permit updates to "display_name" and "email"
if let Some(patch) = sanitize_update(user_updates, &["display_name", "email"]) {
    db.update("tenants/123/users/abc", patch).await;
}

Rule-aware data exposure prevention

Design Firestore security rules to enforce tenant isolation and to reject paths that contain directory traversal patterns. In your rules, explicitly deny document reads or writes that reference parent paths outside the user’s tenant:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /tenants/{tenantId}/users/{userId} {
      allow read, write: if request.auth != null && request.auth.token.tenant_id == tenantId;
    }
    match /tenants/{tenantId}/public/{docId=**} {
      allow read: if request.auth != null && request.auth.token.tenant_id == tenantId;
    }
  }
}

Continuous monitoring and testing

Use the middleBrick Pro plan to enable continuous scanning of your API endpoints and to integrate checks into your CI/CD pipeline. The GitHub Action can fail a build if a scan detects new injection-related findings, ensuring that unsafe patterns are caught before deployment. The MCP Server allows you to run scans directly from your AI coding assistant, helping to validate Firestore interaction patterns during development.