Xpath Injection in Chi with Basic Auth

XPath Injection in the Chi routing ecosystem with HTTP Basic Authentication involves two intersecting concerns: how dynamic XPath expressions are constructed from user input, and how authentication state is handled across requests. Chi is a minimal HTTP router for Go that lets you define routes and middleware, but it does not provide built-in input validation for XPath parameters.

When a handler receives user-controlled data (e.g., a query parameter or header) and uses it to build an XPath expression without escaping or parameterization, an attacker can alter the XPath’s logic. For example, an attacker may inject ' or '1'='1 to change predicate evaluation and bypass intended node selection. This becomes especially risky when the same handler relies on Basic Auth credentials passed via the Authorization: Basic header. If the application uses those credentials to decide which XPath queries to execute (for example, selecting a user-specific XML document or subset), an injection can lead to reading or enumerating data belonging to other users by manipulating both the XPath and the authentication context.

Consider an endpoint like /user/{username} where username is used in an XPath lookup and Basic Auth credentials are used to confirm identity. An attacker could supply a crafted username such as admin' or substring($pwd,1,1)='a while sending a valid Basic Auth header for their own account. If the XPath logic is not isolated per request and the handler merges user input with path selection logic, this can result in Insecure Direct Object Reference (IDOR)-style exposure, where the attacker enumerates or modifies XML resources they should not access. The attack surface is not theoretical; XPath expressions that concatenate strings are prone to these issues, and Basic Auth does not mitigate insecure XPath construction.

Because XPath lacks prepared statement semantics found in SQL, mitigation requires strict input validation, avoiding concatenation of untrusted data, and using whitelist patterns for allowed values. MiddleBrick’s checks for Input Validation and BOLA/IDOR are relevant here, as they help detect whether user-controlled data reaches XPath construction and whether authorization checks are properly scoped. The 5–15 second scan window allows these unauthentored attack paths to be surfaced without requiring credentials, ensuring you detect XPath Injection risks in Chi handlers that also rely on Basic Auth flows.

To prevent XPath Injection in Chi when using Basic Authentication, ensure user input is never directly interpolated into XPath expressions. Use parameterized approaches where possible, and treat credentials as separate from data selection logic. Below are concrete examples demonstrating insecure patterns and their secure alternatives.

Insecure example with concatenated XPath and Basic Auth header parsing:

//go
package main

import (
    "encoding/base64"
    "net/http"
    "strings"

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

func unsafeHandler(w http.ResponseWriter, r *http.Request) {
    auth := r.Header.Get("Authorization")
    if auth != "" && strings.HasPrefix(auth, "Basic ") {
        cred, _ := base64.StdEncoding.DecodeString(auth[6:])
        pair := strings.SplitN(string(cred), ":", 2)
        if len(pair) == 2 {
            username := pair[0]
            // UNSAFE: username directly used in XPath string building
            xpath := "/users/user[name='" + username + "']/data"
            // process xpath against XML document…
        }
    }
}

func main() {
    r := chi.NewRouter()
    r.Get("/user", unsafeHandler)
    http.ListenAndServe(":8080", r)
}

Secure remediation with input validation and avoiding concatenation:

//go
package main

import (
    "encoding/base64"
    "net/http"
    "regexp"
    "strings"

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

var validUsername = regexp.MustCompile(`^[a-zA-Z0-9_]{1,64}$`).MatchString

func secureHandler(w http.ResponseWriter, r *http.Request) {
    auth := r.Header.Get("Authorization")
    if auth == "" || !strings.HasPrefix(auth, "Basic ") {
        http.Error(w, "Unauthorized", http.StatusUnauthorized)
        return
    }
    cred, err := base64.StdEncoding.DecodeString(auth[6:])
    if err != nil {
        http.Error(w, "Bad Request", http.StatusBadRequest)
        return
    }
    pair := strings.SplitN(string(cred), ":", 2)
    if len(pair) != 2 {
        http.Error(w, "Bad Request", http.StatusBadRequest)
        return
    }
    username := pair[0]
    if ! validUsername(username) {
        http.Error(w, "Forbidden", http.StatusForbidden)
        return
    }
    // Use parameterized or controlled lookup instead of string concatenation.
    // Example assumes a function queryXML that uses a prepared-like context.
    data, err := queryXML(r.Context(), "/users/user", username)
    if err != nil {
        http.Error(w, "Not Found", http.StatusNotFound)
        return
    }
    w.Write(data)
}

// queryXML is a placeholder for safe XML access logic that does not concatenate XPath from user input.
func queryXML(ctx context.Context, path, username string) ([]byte, error) {
    // Implementation-specific: use a library that supports compiled queries or structural navigation.
    return nil, nil
}

Key takeaways: validate and restrict username formats, keep credentials separate from XPath construction, and avoid dynamic XPath assembly. MiddleBrick’s scans can verify that your handlers do not expose injection points, and its GitHub Action can enforce these checks in CI/CD before deployment.