Format String in Chi with Basic Auth

A format string vulnerability in a Chi application that also uses HTTP Basic Authentication can amplify information disclosure and enable unexpected behavior when user-controlled input reaches logging or error-handling paths. Chi is a lightweight routing library for Go, and while it does not format strings itself, developers often construct log lines or error messages using values extracted from the request context, including authentication-related data such as the username extracted from the Authorization header.

Consider a scenario where the route handler decodes Basic Authentication credentials and passes the username directly to a logging function using a format verb without proper sanitization. For example, extracting the username from the header and using it in a log statement like log.Printf("User: %s", username) is safe only if the input is controlled. If the username is instead passed with a format string such as log.Printf(username) or log.Printf("User: %s", username) where the format string itself comes from an untrusted source, the application becomes vulnerable. An attacker can supply a crafted username like %s %s %s or include format specifiers such as %x %x %x to read values from the stack, potentially exposing session tokens, internal pointers, or other sensitive data that resides in memory at the time of logging.

In the context of Basic Authentication, the initial credentials are base64-encoded but not encrypted; they are transmitted in the header and decoded server-side. If the decoded username or password is later used in a vulnerable logging or error-reporting path, an attacker who can influence these values may leverage a format string bug to probe memory contents. This can complement other attack behaviors such as enumeration of valid users via timing differences or error messages. Because Chi encourages composable handlers and middleware, the risk arises when handlers or shared logging utilities do not treat authentication-derived inputs as untrusted. The vulnerability is not in Chi itself but in how developers handle and format these values after extraction.

Real-world patterns that increase risk include using third-party log libraries that accept format strings from user data, or constructing HTTP error messages that incorporate the username without using explicit format verbs. For instance, writing fmt.Fprintf(w, "Unauthorized for user " + username) may appear safe but can become dangerous if the username contains format-like sequences and the code is later refactored to use fmt.Fprintf(w, username) or a similar pattern. Developers must ensure that any user-controlled string used in formatted output is passed as a data argument, never as the format string itself, and that logging is configured to avoid verbose or reflective output in production.

Because middleBrick scans the unauthenticated attack surface and tests input validation and data exposure, it can detect indicators that user-controlled inputs are reflected in server-side logs or error responses. The LLM/AI Security checks do not apply here, but the Input Validation and Data Exposure checks help identify whether authentication-derived values are improperly handled in logging or error paths. Remediation focuses on strict formatting discipline and avoiding the use of untrusted data as format templates.

Secure handling of Basic Authentication in Chi requires treating the decoded username and password as untrusted data and ensuring they are never used as format strings. Always use explicit format verbs and pass authentication-derived values as arguments. Below are concrete, idiomatic examples that demonstrate safe extraction and usage within a Chi route.

First, a safe extraction and logging pattern using explicit format verbs:

import (
    "fmt"
    "log"
    "net/http"
    "strings"
)

func authMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        auth := r.Header.Get("Authorization")
        if auth == "" {
            http.Error(w, "Authorization header required", http.StatusUnauthorized)
            return
        }
        const prefix = "Basic "
        if !strings.HasPrefix(auth, prefix) {
            http.Error(w, "Invalid authorization type", http.StatusUnauthorized)
            return
        }
        payload := auth[len(prefix):]
        decoded, err := base64.StdEncoding.DecodeString(payload)
        if err != nil {
            http.Error(w, "Invalid authorization header", http.StatusUnauthorized)
            return
        }
        parts := strings.SplitN(string(decoded), ":", 2)
        if len(parts) != 2 {
            http.Error(w, "Invalid credentials", http.StatusUnauthorized)
            return
        }
        username, password := parts[0], parts[1]
        // Safe: username is passed as a data argument
        log.Printf("User login attempt: %s", username)
        ctx := context.WithValue(r.Context(), "username", username)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

Second, avoid concatenating user input into log or error messages in a way that could reintroduce format risks:

// Unsafe pattern to avoid:
// log.Printf("Unauthorized for user " + username)
// Prefer:
log.Printf("Unauthorized for user %s", username)

Third, ensure that any HTTP error responses do not reflect the password and do not use user input as the format string:

func loginHandler(w http.ResponseWriter, r *http.Request) {
    auth := r.Header.Get("Authorization")
    // ... extraction and decode as above
    if password != expected {
        // Safe: fixed format string with user value as argument
        log.Printf("Failed login for user %s", username)
        http.Error(w, "Invalid credentials", http.StatusUnauthorized)
        return
    }
    // proceed
}

These patterns ensure that usernames extracted from Basic Authentication are treated strictly as data. By using explicit format verbs and avoiding any dynamic format templates, developers mitigate format string risks even when usernames contain unusual characters or sequences. middleBrick’s CLI can validate that your endpoints do not reflect raw authentication values in error or log outputs, while the Dashboard helps track changes over time.