Sql Injection in Axum with Firestore

SQL Injection is commonly associated with SQL databases, but API endpoints that build dynamic queries for any backend—including NoSQL services such as Firestore—can expose injection-like risks when input is improperly handled. In an Axum service that uses Firestore, the vulnerability arises when request parameters, headers, or body values are concatenated into Firestore query components, such as collection or document IDs, filter values, or field paths, without validation or escaping.

Consider a scenario where an endpoint constructs a Firestore document path using user input: an attacker could supply a document ID like users/abc/../../../secrets or a field value designed to manipulate server-side behavior. While Firestore does not support traditional SQL, injection-like effects can occur via malformed queries or path traversal when the application builds references dynamically. If the Axum handler does not validate or sanitize inputs before using them in Firestore operations, the API may expose sensitive documents or allow unauthorized access patterns.

Moreover, Firestore queries that rely on string interpolation to set filter values can be abused if numeric or string inputs are not strictly typed and constrained. For example, concatenating user input into a query filter such as field = 'user_input' without sanitization may allow an attacker to inject crafted values that affect query semantics or bypass intended access controls. Because Firestore indexes and query structures depend on exact value matching, unexpected characters or operators in input can lead to unintended query behavior or data exposure.

In a black-box scan by middleBrick, endpoints that accept external input and directly use it in Firestore operations are tested for injection-like behaviors across multiple security checks, including Input Validation, Property Authorization, and BOLA/IDOR. The scanner evaluates whether untrusted data can influence query construction or document access paths, and reports findings with severity ratings and remediation guidance. This testing approach helps detect risks specific to NoSQL backends in Axum services.

Securing Axum endpoints that interact with Firestore requires strict input validation, canonicalization of document references, and avoiding dynamic query construction based on user-controlled data. Always treat request inputs as untrusted and enforce allowlists for identifiers, document paths, and field values.

Use Firestore’s built-in APIs to reference documents by ID without string concatenation. Instead of building document paths from user input, validate the ID against a strict pattern and then use the collection and document methods explicitly. For example:

use axum::{routing::get, Router, extract::Path};
use google_cloud_firestore::client::Client;
use serde::Deserialize;

#[derive(Deserialize)]
struct QueryParams {
    document_id: String,
}

async fn get_user_handler(
    Path(id): Path,
    client: &State,
) -> Result {
    // Allow only alphanumeric IDs to prevent path traversal
    if !id.chars().all(|c| c.is_alphanumeric() || c == '-' || c == '_') {
        return Err((axum::http::StatusCode::BAD_REQUEST, "Invalid document ID".to_string()));
    }
    let doc_ref = client.collection("users").doc(&id);
    match doc_ref.get().await {
        Ok(document) => {
            if let Some(data) = document.data() {
                Ok(axum::Json(data))
            } else {
                Err((axum::http::StatusCode::NOT_FOUND, "Not found".to_string()))
            }
        }
        Err(e) => Err((axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string())),
    }
}

fn user_router() -> Router {
    Router::new().route("/users/:document_id", get(get_user_handler))
}

This pattern ensures that document IDs are constrained before being used in Firestore operations, reducing the risk of path traversal or malformed references. For queries involving field values, use Firestore’s parameter binding and avoid string interpolation. For example, when filtering documents by a known field, construct the query using Firestore’s query API rather than concatenating values into a string-based filter expression.

Additionally, apply principle of least privilege to Firestore credentials used by the Axum service. Ensure that service account permissions are scoped to the minimum required operations and collections. Combine this with continuous monitoring via the middleBrick Pro plan, which can run scheduled scans and alert you if a new endpoint introduces injection-like risks. For development workflows, the middlebrick CLI can be integrated into scripts to validate endpoint behavior before deployment.