Xml External Entities in Actix with Firestore

An XML External Entity (XXE) vulnerability occurs when an application processes XML input that references external entities. In an Actix web service that accepts XML payloads and interacts with Google Firestore, the risk emerges if the server deserializes untrusted XML and passes attacker-controlled data into Firestore operations. Attackers can craft XML that defines malicious external entities, causing the XML parser to read local files, make internal network requests, or consume excessive resources. When the application then writes parsed data to Firestore—such as user profiles or configuration documents—the tainted data may be stored or retrieved later, exposing sensitive information or altering behavior.

Consider an endpoint in Actix that receives an XML document containing user metadata and stores it in a Firestore collection. If the XML parser is not explicitly hardened (e.g., disabling external entity resolution and DTDs), an attacker can supply an entity like &file SYSTEM "/etc/passwd" that gets expanded during parsing. The resulting data, now containing sensitive file contents, could be saved to Firestore fields or used in queries. Firestore itself does not process XML, but the application layer does; therefore, insecure XML handling in Actix leads to data integrity and information disclosure issues that manifest through Firestore-stored content. Additionally, XXE can enable SSRF against internal services reachable from the Actix runtime, compounding the impact when Firestore hosts sensitive project data.

In practice, this vulnerability maps to the OWASP API Top 10 category ‘Broken Object Level Authorization’ and ‘Security Misconfiguration’ when XML parsing is overly permissive. Because middleBrick tests for BOLA/IDOR and Input Validation as part of its 12 parallel checks, an API that accepts XML without restricting entity resolution may receive a high-risk score. The presence of LLM endpoints or exported schemas does not mitigate XXE; instead, strict parser configuration and input validation are required to ensure that untrusted XML cannot influence Firestore writes or reads.

To secure Actix endpoints that interact with Firestore, disable external entity processing in the XML parser and validate/sanitize all data before writing to Firestore. Use a dedicated XML library that supports secure defaults, and ensure that any data destined for Firestore fields is validated for type, length, and content.

Example: Secure XML parsing and Firestore write in Actix (Rust)

use actix_web::{web, HttpResponse, Responder};
use roxmltree::Document;
use google_firestore1::FirestoreDb;
use std::collections::HashMap;

/// Secure handler: parse XML without external entities, then write to Firestore.
async fn submit_profile(xml_body: String, db: web::Data<FirestoreDb>) -> impl Responder {
    // Parse XML with external entities and DTDs disabled.
    let doc = match Document::parse(&xml_body) {
        Ok(d) => d,
        Err(e) => return HttpResponse::BadRequest().body(format!("Invalid XML: {}", e)),
    };

    // Extract only expected fields; ignore unexpected nodes.
    let mut profile_data = HashMap::new();
    for node in doc.root().children() {
        if node.is_element() {
            let tag = node.tag_name().name();
            let text = node.text().unwrap_or("").trim();
            // Allow only known fields to prevent injection of malicious data.
            match tag {
                "username" | "email" | "preferences" => {
                    profile_data.insert(tag.to_string(), text.to_string());
                }
                _ => {
                    // Log and reject unexpected elements.
                    return HttpResponse::BadRequest().body(format!("Unexpected element: {}", tag));
                }
            }
        }
    }

    // Write sanitized data to Firestore (document ID derived from authenticated user).
    // In real code, include proper error handling and authentication checks.
    let user_id = "authenticated_user_id"; // obtain from request extensions or auth middleware
    db.firestore
        .doc(&format!("users/{}", user_id))
        .set(&profile_data)
        .await;

    HttpResponse::Ok().body("Profile stored securely")
}

Key points in the example:

• Uses roxmltree, which does not resolve external entities by default, avoiding XXE by design.
• Explicitly allows only known fields (username, email, preferences) and rejects any other XML elements, enforcing strict input validation.
• Writes sanitized, type-checked data to Firestore using the Firestore client library, ensuring that stored documents do not contain unexpected or malicious content.

Additional hardening measures

Combine the parsing controls with runtime security practices such as validating data schemas (e.g., using Serde with strict deserialization rules), applying size limits on incoming payloads, and monitoring Firestore access patterns for anomalies. These measures reduce the impact of misconfigurations and ensure that even if unexpected data reaches Firestore, it does not lead to privilege escalation or unintended behavior.