Unicode Normalization in Actix with Firestore

Unicode normalization inconsistencies arise when an Actix service accepts user input (e.g., identifiers, keys, or paths), stores it in Cloud Firestore, and later compares or retrieves data without normalizing to a canonical form. Attackers can supply visually identical code points that normalize to different binary strings, bypassing access controls or causing data mismatch.

In an Actix web service, a route might use a user-supplied document ID to read from Firestore. If the ID contains composed characters (e.g., é as U+00E9) and Firestore stores the decomposed form (e.g., e + ◌́ as U+0065 U+0301), a naive equality check may treat them as distinct. An attacker could register, then log in using a visually identical but normalized variant to escalate privileges or access another user’s data.

Firestore does not enforce a specific Unicode normalization form on string values; it stores strings as UTF-8 byte sequences. Actix must normalize inputs before constructing queries or document paths. For example, using the same normalization form for both reads and writes ensures consistent key matching. Without this, an ID like café (composed) may not match a stored ID café (decomposed), leading to authorization issues or broken object-level references (BOLA/IDOR).

Additionally, normalization affects metadata used in inventory management and property authorization checks reported by middleBrick. If normalized and non-normalized values appear in different documents or fields, inventory scans may flag mismatches or unexpected access patterns, increasing the risk score. MiddleBrick’s checks for BOLA/IDOR and Input Validation highlight these inconsistencies, emphasizing the need to normalize before any Firestore operation.

Real-world attack patterns include using homoglyphs or combining characters to impersonate usernames or resource identifiers. For compliance mappings, these issues align with OWASP API Top 10 A01:2023 (Broken Object Level Authorization) and A05:2023 (Injection), as inconsistent normalization can lead to unauthorized data access or injection-like behavior in queries.

To detect such risks, middleBrick runs parallel security checks including Unicode handling within Input Validation and BOLA/IDOR, reporting findings with severity and remediation guidance. Pro plan continuous monitoring can alert you when new endpoints exhibit normalization-sensitive behavior, while the CLI provides JSON output for automation.

Remediation centers on normalizing all string inputs to a single Unicode form (NFC or NFD) before using them in Firestore document IDs, query values, or path construction. Choose NFC for general use, as it is the canonical composition recommended by Google and most web platforms.

In Actix, implement a normalization middleware or helper that processes relevant fields. Use the unicode-normalization crate to ensure consistent handling across request handling and Firestore interactions.

// Cargo.toml dependencies
// unicode-normalization = "0.1"
// firestore = "0.10"

use actix_web::{dev::ServiceRequest, Error, HttpMessage};
use actix_web::http::header::AUTHORIZATION;
use futures_util::future::{ok, Either, Ready};
use unicode_normalization::UnicodeNormalization;

/// Normalize a string to NFC.
fn to_nfc(s: &str) -> String {
    s.nfc().collect()
}

/// Extract and normalize an identifier from headers or path.
fn normalize_input(value: &str) -> String {
    // Example: normalize user IDs, document references, or keys
    to_nfc(value.trim())
}

/// Example Firestore read using normalized ID in Actix request handler.
async fn get_user_document(
    doc_id: String,
    db: web::Data,
) -> Result {
    let normalized_id = normalize_input(&doc_id);
    // Use the normalized ID for consistent Firestore document paths.
    let user: Option = db
        .get(&format!("users/{}", normalized_id))
        .await
        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
    Ok(web::Json(user))
}

/// Example Firestore write with normalized key.
async fn create_user_document(
    payload: web::Json,
    db: web::Data,
) -> Result {
    let normalized_id = normalize_input(&payload.user_id);
    let user = User::from_payload(&payload);
    db.set(&format!("users/{}", normalized_id), &user)
        .await
        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
    Ok(HttpResponse::Created().finish())
}

For query values that are not document IDs, apply normalization before passing to Firestore filters. Firestore string comparisons are binary-sensitive, so consistent normalization prevents missed matches.

In the GitHub Action, configure a threshold so that if middleBrick detects normalization-related BOLA/IDOR findings, the build fails. The MCP Server can surface these issues directly in your AI coding assistant, suggesting normalization fixes as you write handlers.

When using the Dashboard to track scores over time, monitor changes in Input Validation and BOLA/IDOR categories after deploying normalization fixes. The CLI can export JSON reports for audit trails, and the Pro plan’s continuous monitoring will highlight regressions on a configurable schedule.