Xpath Injection in Axum with Mutual Tls

XPath Injection occurs when untrusted input is concatenated into an XPath expression without proper sanitization or parameterization, allowing an attacker to alter query logic and access unauthorized data. In Axum handlers, this typically arises when building XPath strings for XML processing based on request parameters, headers, or cookies. Mutual Transport Layer Security (Mutual TLS) ensures strong client authentication via client certificates, but it does not sanitize or validate application-level input. Therefore, even when Mutual TLS confirms the identity of the client, the application must still treat all authenticated input as untrusted.

Consider an Axum handler that receives a client certificate containing a user identifier and uses it to construct an XPath query to retrieve user-specific XML data:

// BAD: concatenating certificate subject into XPath
let user_dn = get_peer_cert_subject(req); // e.g., "CN=alice,OU=dev"
let query = format!("/users/user[dn='{}']/data", user_dn);
let result = evaluate_xpath(&xml_doc, &query);

If the certificate subject is attacker-controlled (e.g., via a compromised or malicious certificate), an attacker can inject XPath syntax such as ' or 1=1 or ' to bypass intended scoping. With Mutual TLS, the server may trust the client more implicitly, potentially reducing logging or rate-limiting for authenticated sessions, which can make injection attempts less noticeable. The XPath Injection maps to the OWASP API Top 10 category Broken Object Level Authorization (BOLA) and can lead to unauthorized data exposure. It is important to note that middleBrick detects such issues by correlating authenticated request patterns with XPath construction and flags findings under Authorization and Input Validation checks.

In a production scenario using Axum with Mutual TLS, the server validates client certificates before routing to handlers. If the handler then builds dynamic XPath expressions using certificate-derived fields without escaping, the combination creates a trust boundary bypass at the data layer. Attackers may leverage special XPath functions or path traversals to read arbitrary XML nodes. middleBrick’s scans include checks for Unsafe Consumption and Input Validation that can surface these patterns when scanning endpoints that process XML and authenticated credentials together.

Remediation focuses on never concatenating authenticated or request-derived data directly into XPath expressions. Use parameterized XPath evaluation where supported, or strict escaping and allowlisting. Below are concrete Axum examples demonstrating secure handling when Mutual TLS is in use.

1. Avoid XPath string building; use parameterized APIs

If your XML library supports parameterized evaluation, bind values explicitly. This is the most robust approach:

// GOOD: parameterized XPath (library-dependent; example using a hypothetical API)
let user_dn = get_peer_cert_subject(req).unwrap_or("unknown");
// Assume `eval_xpath_param` binds variables safely
let result = eval_xpath_param(
    &xml_doc,
    "/users/user[dn=$dn]/data",
    &[("dn", &user_dn)],
);

2. Allowlist certificate fields

Extract only the necessary, predictable fields from the certificate and validate them against an allowlist before use:

// GOOD: allowlist certificate common name against known users
let user_dn = get_peer_cert_subject(req).unwrap_or("unknown");
let allowed_users = ["alice", "bob", "charlie"];
let username = user_dn
    .strip_prefix("CN=")
    .filter(|name| allowed_users.contains(&name.as_str()))
    .unwrap_or("guest");
// Use a parameterized or escaped query
let query = format!("/users/user[name='{}']/data", escape_xpath_literal(username));
let result = evaluate_xpath(&xml_doc, &query);

3. Escape literals rigorously

When parameterization is unavailable, apply strict escaping for string literals in XPath. For example, replace single quotes with two single quotes and reject input containing disallowed XPath axes or functions:

// GOOD: escape and sanitize before inclusion
fn escape_xpath_literal(value: &str) -> String {
    value.replace("'", "''")
}

// In handler
let user_dn = get_peer_cert_subject(req).unwrap_or("unknown");
let safe_dn = escape_xpath_literal(user_dn);
let query = format!("/users/user[dn='{}']/data", safe_dn);
let result = evaluate_xpath(&xml_doc, &query);

4. Axum extractor discipline

Keep certificate extraction separate from query building and log suspicious values without exposing them in production responses:

// GOOD: extract, validate, and log safely
async fn handler(
    req: Request,
    Extension(certs): Extension>,
) -> Result {
    let subject = certs.first()
        .map(|c| c.subject().to_string())
        .unwrap_or_else(|| "no-cert".to_string());

    // Validate against allowlist
    if !is_valid_subject(&subject) {
        return Err((StatusCode::FORBIDDEN, "invalid certificate")).into_response();
    }

    // Build query safely
    let query = build_user_query(&subject); // uses escaping or parameterization
    let data = fetch_data_via_xpath(&query).await?;
    Ok(Json(data))
}

With Mutual TLS, it is still essential to apply these practices because authentication does not equate to input integrity. Using middleBrick’s CLI, you can verify remediation by scanning the endpoint after changes:

$ middlebrick scan https://api.example.com/users