Xpath Injection in Chi with Mutual Tls

XPath Injection occurs when an attacker can influence an XPath expression constructed with untrusted input, leading to authentication bypass or data exfiltration. In Chi, a common pattern is to build an XPath string for user lookup using URL or header values, for example concatenating a token directly into the expression. When Mutual TLS is used, the server may treat the client certificate subject or serial number as trusted input, because mTLS is assumed to guarantee identity. This assumption can lead to insecure concatenation, where the certificate-derived value is interpolated into the XPath without validation or parameterization. Because mTLS ensures channel-level identity, developers might mistakenly believe application-layer authorization is unnecessary, increasing the risk of insecure XPath construction.

An attacker who can control or influence the XPath string may escape the intended predicate and modify the query logic. For instance, given a base XPath like /users/user[token="{user_token}"], an attacker-supplied token such as " or "1"="1 can change the result set to match unintended users. In a Chi route that resolves a client certificate and uses its fields to build queries, this becomes: extract the certificate serial number, interpolate it into an XPath lookup for a user record, and then perform authorization decisions based on the query result. If the XPath is built via string concatenation (e.g., fmt.Sprintf), the attacker can manipulate the effective query even when mTLS is enforced, because the certificate value is still user-controlled from an application perspective. The vulnerability is not in mTLS itself, but in how the application uses mTLS-derived data in XPath expressions without sanitization, parameterization, or strict schema enforcement.

Chi does not automatically sanitize inputs derived from mTLS metadata. Without explicit validation and strict XPath parameterization (such as using variables or compiled expressions), the combination of dynamic query building and mTLS-based identity creates an exploitable surface. This mirrors classic Injection patterns in other contexts and is detectable by security scans that analyze endpoint behavior and spec definitions, highlighting insecure query construction and missing input constraints.

Remediation focuses on never using mTLS-derived data directly in XPath construction. Instead, treat certificate metadata as identity claims and map them to application identifiers via a secure lookup, then use parameterized queries or strict filtering. Below are concrete Chi patterns that reduce risk.

Example 1: Safe mapping and parameterized XPath-like filtering

Use the certificate subject to look up a known user record via a controlled data store, then apply filters using placeholders or structured queries rather than string interpolation.

import (
    "context"
    "fmt"
    "net/http"

    "github.com/go-chi/chi/v5"
    "github.com/go-chi/chi/v5/middleware"
)

// Simulated secure user store
type UserStore map[string]User

type User struct {
    ID       string
    Username string
}

var store = UserStore{
    "SN123456": {ID: "u1", Username: "alice"},
}

func getUsernameFromCert(r *http.Request) (string, bool) {
    // In practice, extract the serial or subject from the TLS state.
    // Here we simulate it for demonstration.
    cert := r.TLS.PeerCertificates
    if len(cert) == 0 {
        return "", false
    }
    // Use serial number as a key; ensure it is validated and normalized.
    serial := fmt.Sprintf("%d", cert[0].SerialNumber)
    return serial, true
}

func safeHandler(w http.ResponseWriter, r *http.Request) {
    serial, ok := getUsernameFromCert(r)
    if !ok {
        http.Error(w, "missing client cert", http.StatusUnauthorized)
        return
    }

    // Map certificate serial to application user via controlled lookup.
    user, exists := store[serial]
    if !exists {
        http.Error(w, "user not found", http.StatusForbidden)
        return
    }

    // Use user.ID in a parameterized context; avoid XPath/string interpolation.
    // If querying a database, use prepared statements or ORM parameterization.
    // Example pseudo-query (not XPath): SELECT * FROM permissions WHERE user_id = ?
    _ = user.ID

    fmt.Fprintf(w, "authenticated as %s", user.Username)
}

func main() {
    r := chi.NewRouter()
    r.Use(middleware.RealIP)
    r.Use(middleware.SSLRedirect)
    r.Get("/profile", safeHandler)
    http.ListenAndServeTLS(":8443", "server.crt", "server.key", r)
}

In this example, the certificate serial is used only to index a local store. The application never builds an XPath string from the raw certificate value, preventing injection via maliciously crafted inputs that might otherwise be possible if the serial were concatenated into a query.

Example 2: Rejecting unexpected certificate fields and enforcing schema

Validate certificate extensions or custom OIDs against an allowlist, and reject certificates that contain unexpected data. This reduces the attack surface where an attacker might influence fields used in XPath-like queries.

func validateCertExtensions(cert *x509.Certificate) error {
    // Enforce that only specific extensions are present.
    for _, ext := range cert.Extensions {
        switch ext.Id.String() {
        case "1.2.3.4": // expected OID
            continue
        default:
            return fmt.Errorf("unexpected extension: %s", ext.Id)
        }
    }
    return nil
}

By combining strict validation, secure mapping, and avoidance of runtime string-to-expression construction, you mitigate XPath Injection risks in a mTLS-enabled Chi application.