Xml External Entities in Axum with Firestore

XML External Entity (XXE) injection occurs when an application processes XML input that references external entities in a way that the parser resolves them. In an Axum application using Firestore as a backend, the risk emerges when user-controlled data is deserialized as XML before being forwarded to Firestore or when Axum receives XML payloads in request bodies (for example, through a webhook or API endpoint that accepts XML). Axum is a web framework for Rust and does not parse XML by default, but if the application adds an XML deserializer or passes raw XML strings to Firestore client libraries that forward data to external services, an attacker can craft malicious XML that defines external entities pointing to local resources, internal metadata services, or remote endpoints.

Consider an Axum handler that accepts an XML document containing user profile information to be stored in Firestore. If the XML parser resolves DOCTYPE declarations with SYSTEM or PUBLIC URLs, an attacker-supplied external entity can read files from the filesystem (e.g., /etc/passwd) or trigger SSRF against internal metadata endpoints (e.g., http://169.254.169.254). Because Firestore stores and indexes data, any exfiltrated content may be persisted and later accessible via legitimate queries. Similarly, if the Firestore client is used inside a server that also processes XML from untrusted sources, the combination of a vulnerable XML parser in the request pipeline and Firestore’s data storage creates a path where sensitive data can be disclosed or internal infrastructure probed without proper network isolation.

Another scenario involves webhook integrations where third-party systems send XML payloads to an Axum endpoint before the data is written to Firestore. If the XML parser resolves external entities, attackers can cause the server to make arbitrary outbound HTTP requests (SSRF) to internal services that the Firestore integration trusts, potentially bypassing firewall rules. Insecure default parser configurations, such as enabling external-general-entities or external-parameter-entities, amplify the risk. Even when Firestore itself does not parse XML, the persistence layer can reflect injected entity content through application logic, enabling data exfiltration or authentication bypass if entity values are used to influence access control decisions.

Because middleBrick tests unauthenticated attack surfaces and includes input validation checks, it can surface XXE indicators when XML inputs trigger unexpected parser behavior or when Firestore write patterns expose stored sensitive data. The scanner’s input validation tests help highlight cases where XML deserialization occurs without disabling external entity resolution. Since Firestore stores structured data, any injected content that reaches Firestore documents may remain accessible until explicitly removed, underscoring the importance of validating and sanitizing XML inputs before any persistence operation in Axum-based services.

To prevent XXE in an Axum application that interacts with Firestore, ensure XML parsing is either removed or hardened. The safest approach is to avoid XML entirely; use JSON for request payloads and configure Axum extractors to reject XML content types. If XML support is required, use a Rust XML parser with external entity resolution explicitly disabled. For Firestore operations, rely on strongly typed structures and the official Firestore SDK, avoiding raw string concatenation or deserialization of untrusted data into Firestore document writes.

Example: A secure Axum handler that accepts JSON and writes to Firestore using the Firestore SDK in Rust (using the google-rs or firestore-rs ecosystem crates) looks like this:

use axum::{routing::post, Router, Json};
use serde::{Deserialize, Serialize};
use firestore::*; // hypothetical Firestore SDK crate
use std::net::SocketAddr;

#[derive(Debug, Deserialize, Serialize)]
struct UserProfile {
    name: String,
    email: String,
}

async fn create_profile(
    Json(payload): Json,
) -> Result {
    // Initialize Firestore client (configuration omitted for brevity)
    let client = FirestoreClient::new("my-project").map_err(|e| {
        (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string())
    })?;

    let doc_path = "users/profiles/";
    client
        .create(doc_path, &payload)
        .await
        .map_err(|e| (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    Ok("created".to_string())
}

#[tokio::main]
async fn main() {
    let app = Router::new().route("/profiles", post(create_profile));
    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

If you must process XML, disable external entities explicitly. For example, using the quick-xml crate with safe settings and avoiding any DOCTYPE processing:

use quick_xml::Reader;
use quick_xml::events::Event;

fn parse_safe_xml(input: &str) -> Result<(), String> {
    let mut reader = Reader::from_str(input);
    reader.trim_text(true);
    // Ensure no DTD or external entities are processed
    let mut buf = Vec::new();
    loop {
        match reader.read_event_into(&mut buf) {
            Ok(Event::Eof) => break Ok(()),
            Ok(_) => { /* handle element/text */ }
            Err(e) => return Err(format!("XML error: {}", e)),
        }
        buf.clear();
    }
}

Additionally, apply strict Content-Type validation in Axum routes to reject application/xml when JSON is expected, and enforce size limits on request bodies to mitigate resource exhaustion. For Firestore-specific hardening, use the Firestore SDK’s built-in validation and avoid storing raw XML strings in documents. The middleBrick CLI can be used in CI to verify that endpoints reject XML or unsafe content types and that Firestore write operations do not reflect unchecked input.