Formula Injection in Actix with Firestore

Formula Injection occurs when user-controlled data is inserted into formulas or expressions that are later evaluated by a downstream system. In Actix web applications that use Google Firestore as a backend, this typically happens when string values from HTTP requests—such as query parameters, path segments, or JSON payload fields—are used to construct Firestore queries or document fields that contain spreadsheet-like formulas (for example, values intended for downstream processing in tools like Excel or Google Sheets).

Consider an endpoint that exports financial data and allows a user to specify a calculation template stored as a string. If the application directly interpolates user input into the template without validation or escaping, an attacker can supply formulas such as =cmd|' /C calc'!A0 or =HYPERLINK("javascript:alert(1)"). When the document is later opened in a spreadsheet client, the injected formula executes in the client context. In an Actix + Firestore setup, the application might retrieve a document from Firestore, populate a field with unsanitized user input, and return the resulting file to the client. Because Firestore does not inherently treat strings as executable formulas, the vulnerability is not in Firestore itself but in how the Actix service handles, transforms, and serves data that may be interpreted as formulas downstream.

Firestore-specific risks in this context arise when query construction reflects user input into field values or map keys that are later exported and interpreted by other systems. For example, an Actix handler might read a Firestore document, apply user-supplied parameters to build a response map, and serialize it to CSV or XLSX. If the user can control keys or values that end up in cells prefixed with =, and the export pipeline does not sanitize or escape these values, the exported file becomes a vector for Formula Injection. Additionally, if Firestore document IDs or field names are derived from user input and later used in dynamically constructed formulas (for example, via string concatenation in the Actix layer), the risk increases because the boundaries between data and code are blurred.

An illustrative Actix handler using the Firestore Rust SDK might look like this, showing a vulnerable pattern where a user-provided prefix is placed into a response value that could be interpreted as a formula:

use actix_web::{web, HttpResponse};
use google_cloud_firestore::client::Client;

async fn export_data(client: web::Data, query: web::Query>) -> HttpResponse {
    let prefix = query.get("prefix").unwrap_or(&"=".to_string());
    // Vulnerable: directly using user-controlled prefix in a value
    let value = format!("{prefix}12345");
    // Imagine this map is later exported to CSV/XLSX and opened in a spreadsheet
    let response = serde_json::json!({
        "label": "result",
        "formula": value
    });
    HttpResponse::Ok().json(response)
}

In this example, an attacker supplying ?prefix==cmd|' /C calc'!A0 would produce a response field that, when placed into a spreadsheet-compatible export, triggers unintended behavior. Although Firestore stores the string as-is, the downstream consumption layer interprets it as executable content, demonstrating how the combination of Actix request handling and Firestore data storage enables the injection path.

Because middleBrick scans test unauthenticated attack surfaces and include checks such as Input Validation and Unsafe Consumption, it can surface indicators that user-controlled data reaches output formats where formulas may be interpreted. The scanner does not fix the issue but provides findings with remediation guidance to help developers sanitize and escape data at the point of construction and export.

Remediation focuses on ensuring that user-controlled data never directly participates in formula construction and that any exported representation neutralizes special leading characters. In Actix applications using Firestore, you should treat all user input as opaque data and apply context-specific escaping when generating files or dynamic expressions.

For CSV exports, prepend a single quote (') to values that could be interpreted as formulas. This is a widely supported convention in spreadsheet software that forces the cell to be treated as plain text. In Rust, you can implement a small helper to sanitize values before they enter the export pipeline:

fn sanitize_for_csv(value: &str) -> String {
    if value.starts_with('=') || value.starts_with('+') || value.starts_with('-') || value.starts_with('@') {
        format!("\'{}", value)
    } else {
        value.to_string()
    }
}

Apply this function to any string that will be placed into a CSV cell. For more robust document generation, prefer structured formats such as JSON for internal interchange and generate spreadsheets using a library that handles escaping automatically.

When constructing Firestore queries, avoid using user input to build field names or document IDs that later feed into formula generation. Instead, use controlled mappings. For example, rather than concatenating user input into a field name, use a predefined set of allowed keys:

use actix_web::{web, HttpResponse};
use google_cloud_firestore::client::Client;

async fn safe_export(client: web::Data, query: web::Query>) -> HttpResponse {
    let user_key = query.get("key").unwrap_or(&"default".to_string());
    // Define an allowlist instead of reflecting user input into keys
    let allowed_keys = ["sales", "inventory", "forecast"];
    let selected = if allowed_keys.contains(&user_key.as_str()) {
        user_key
    } else {
        "default"
    };
    // Fetch a document using a controlled field name
    let doc_ref = client.collection("templates").doc(selected);
    match doc_ref.get().await {
        Ok(snapshot) => {
            if let Some(data) = snapshot.map(|d| d.data()) {
                // Further processing…
                HttpResponse::Ok().json(data)
            } else {
                HttpResponse::NotFound().body("template not found")
            }
        }
        Err(_) => HttpResponse::InternalServerError().body("database error"),
    }
}

When exporting data retrieved from Firestore into formats that support formulas (e.g., Excel with Apache POI or a custom XLSX generator), ensure that string cells are explicitly marked as shared strings or formatted to avoid interpretation as expressions. The key principle is to separate data from evaluation context: keep Firestore as a source of trusted data, and enforce escaping or encoding at the point where data transitions into a context where a leading = could be meaningful.

Because middleBrick’s free tier allows up to three scans per month, you can regularly validate that user-controlled endpoints no longer reflect raw input into formula-capable outputs. For ongoing protection, the Pro plan supports continuous monitoring and can integrate with CI/CD pipelines to fail builds if risk scores exceed your chosen thresholds.