Xpath Injection in Actix with Mutual Tls

XPath Injection occurs when an attacker can influence an XPath expression used to query an XML document, enabling authentication bypass, data extraction, or privilege escalation. In Actix web applications that process XML payloads (for example, SAML assertions, legacy configuration formats, or SOAP-based integrations), developers often construct XPath strings by concatenating user-controlled input. This becomes dangerous even when the service enforces Mutual TLS (mTLS), because mTLS provides transport-layer identity and authentication but does not change how the application parses and uses data once the TLS handshake completes.

Mutual TLS ensures the client possesses a valid certificate and that the server validates it, which can create a false sense of security. Teams may assume that mTLS alone protects the backend, leading them to skip input validation and parameterized queries for XML/XPath handling. In practice, an authenticated client with a valid certificate can still supply malicious XPath fragments via request bodies, query parameters, or headers that the application embeds into dynamic XPath expressions. For example, an attacker may provide a username like admin' or '1'='1 as part of an XML field, causing the XPath to return unintended nodes and bypass authorization checks.

Consider an Actix service that authenticates requests with client certificates and then queries an XML document using a path built from a user-supplied identifier:

let user_supplied = ...; // extracted from XML, JSON, or form data
let xpath = format!("/users/user[name='{}']/secret", user_supplied);
let node = document.evaluate(&xpath, ...);

If user_supplied is not escaped or parameterized, an attacker can inject additional predicates or terminate the string early. This can lead to reading other users’ data or escalating access, despite mTLS confirming the client’s identity. The combination of strong client authentication and insufficient input handling can therefore increase risk: mTLS narrows the set of trusted clients, but each trusted client gains a broader attack surface if the application does not treat its data as untrusted.

XPath Injection maps to the OWASP API Top 10 category ‘Broken Object Level Authorization’ and can be detected by middleBrick’s BOLA/IDOR and Input Validation checks. These scans exercise the unauthenticated attack surface and, when mTLS is required, can be configured to present valid client certificates to reach endpoints that rely on certificate-based auth. The scanner will flag unsafe string concatenation in XPath construction and highlight the absence of parameterized queries or robust schema-based validation.

Remediation centers on treating XML data and XPath expressions with the same rigor you apply to certificate validation. Do not rely on mTLS to sanitize inputs; instead, use parameterized XPath APIs, strict schema validation, and strict allowlists for identifiers. Below are concrete Actix patterns that reduce XPath Injection risk while preserving mTLS-based client authentication.

1. Use a safe XPath library or DOM lookup instead of string formatting. Many XML libraries support compiled expressions or namespace-aware lookup that avoid injection. For example, using roxmltree to navigate by element and attribute values is safer than building a raw XPath string:

use roxmltree::Document;

fn find_user_secret(doc: &Document, username: &str) -> Option<String> {
    // Iterate by element/attribute, not string-concatenated XPath
    doc.descendants()
        .find(|n| n.has_tag_name("user") && n.attribute("name") == Some(username))
        .and_then(|user| user.children().find(|c| c.has_tag_name("secret")))
        .map(|secret| secret.text().unwrap_or("").to_string())
}

This approach eliminates XPath syntax in user input and relies on structural traversal, which is not susceptible to injection.

2. If you must use XPath, prefer a library that supports parameterized expressions. Some crates allow you to bind variables to an expression, ensuring user input is treated as data, not as part of the expression syntax:

// Example using a hypothetical safe XPath wrapper; adapt to your actual library.
let expr = xpath.compile("/users/user[name=$username]/secret")?;
let node = expr.evaluate_with_params(&doc, params! { "username" -> username })?;

3. Validate and normalize certificate identity against application-level identifiers. Do not assume the certificate subject maps directly to an XML node or a username. After mTLS authentication, map the certificate to an application-specific principal using a whitelist or a database lookup, then use that principal in safe queries:

use actix_web::HttpRequest;
use openssl::x509::X509;

fn map_cert_to_user(cert: &X509) -> Option<String> {
    let subject = cert.subject_name().to_string();
    // Whitelist or lookup instead of trusting the subject directly
    VALID_USERS.iter().find(|u| subject.contains(u)).cloned()
}

// Later in handler:
let user = map_cert_to_user(cert).ok_or_else(|| error::ErrorUnauthorized("unknown cert"))?;
let secret = find_user_secret(&doc, &user); // uses safe lookup from above

4. Harden XML parsing and schema validation. Reject XML that references external entities or uses constructs that can expand attack surface. In Actix, you can enforce this at the extractor level:

use actix_web::web::Bytes;
use xml::reader::{EventReader, XmlEvent};

fn safe_xml_parser(body: Bytes) -> Result<Document, Error> {
    let parser = EventReader::from_reader(body.as_ref());
    for event in parser {
        match event {
            Ok(XmlEvent::StartElement { name, attributes, namespace }) => {
                // Reject external entities and DOCTYPE if not needed
                if name.local_name == "DOCTYPE" {
                    return Err(Error::BadRequest("DOCTYPE not allowed"));
                }
                // Normal processing...
            }
            // handle other events
            _ => {}
        }
    }
    // Build document safely or stream-process
    Ok(Document::parse(&String::from_utf8_lossy(&body))?)
}

Combine these practices: use mTLS for strong client identification, but always validate and parameterize any data derived from the request, including XML content. This prevents attackers from leveraging trusted certificates to inject malicious XPath.