Header Injection in Chi with Mutual Tls

Header Injection in the Chi web framework occurs when untrusted data from a client request is reflected into HTTP response headers without validation or sanitization. This is typically a consequence of unsafe header construction patterns, such as concatenating user input directly into values assigned to res.Header().Set(). When Mutual Transport Layer Security (Mutual Tls) is enabled, the server also requests and validates a client certificate during the TLS handshake, which establishes strong identity assurance for the client. However, Mutual Tls does not sanitize or normalize application-level headers; it only governs how the connection is established. As a result, an attacker that presents a valid client certificate can still supply malicious input that reaches application handlers, enabling Header Injection if the handler incorrectly uses that input in headers such as X-Forwarded-For, X-Forwarded-Proto, or custom headers.

Mutual Tls changes the trust boundary but does not change the need for strict input validation. For example, an endpoint that reads a certificate subject or a Common Name (CN) from the TLS connection and then places it into a response header without sanitization can expose injection via crafted certificate fields or via additional form/query parameters that are improperly merged into header values. Attack patterns include CRL injection, HTTP response splitting, and header smuggling, where newline characters in injected values cause subsequent headers or the response body to be interpreted as new headers. Chi applications that combine Mutual Tls with permissive header assembly are therefore vulnerable to these classes of injection even though the transport layer is authenticated and encrypted.

Real-world examples include using values from request context or query parameters to construct security-related headers such as Strict-Transport-Security or Content-Security-Policy without proper encoding. Because Mutual Tls ensures the identity of the client, developers may mistakenly assume that the data derived from the connection is safe, increasing the likelihood of insecure concatenation. The OWASP API Top 10 category on Injection applies here, and findings may map to related compliance frameworks such as PCI-DSS and SOC2 when header integrity is required for audit logging or security controls.

Remediation focuses on validating and sanitizing any data used to construct HTTP headers, regardless of the Mutual Tls state. Never directly interpolate values from certificates, query parameters, or headers into response headers without strict allowlisting and escaping. For header values that must reflect client identity, extract the identity from the TLS connection and transform it into a safe representation, such as a normalized identifier or hash, before using it in headers.

import (
    "crypto/tls"
    "net/http"
    "strings"

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

// Safe handler that uses Mutual Tls client certificate info without injection risk.
func safeHandler(res http.ResponseWriter, req *http.Request) {
    // In Mutual Tls, the client certificate is available via TLS state.
    tlsState := req.TLS
    if tlsState == nil || len(tlsState.PeerCertificates) == 0 {
        http.Error(res, "missing client certificate", http.StatusForbidden)
        return
    }
    cert := tlsState.PeerCertificates[0]

    // Validate and sanitize before using in headers.
    subject := cert.Subject.String()
    safeValue := strings.ReplaceAll(subject, "\n", "_")
    safeValue = strings.ReplaceAll(safeValue, "\r", "_")

    // Use a prefixed, allowlisted header.
    res.Header().Set("X-Client-Subject-Safe", safeValue)
    res.WriteHeader(http.StatusOK)
    res.Write([]byte("OK"))
}

// Router setup with Mutual Tls config (server-side certs handled separately).
func makeRouter() *chi.Mux {
    r := chi.NewRouter()
    r.Get("/safe", safeHandler)
    return r
}

// Example server configuration enabling request client certificate verification.
func configureServer() *http.Server {
    tlsConfig := &tls.Config{
        ClientAuth: tls.RequireAndVerifyClientCert,
        ClientCAs:  loadClientCertPool(), // provide a pool of trusted CAs
    }
    return &http.Server{
        Addr:      ":8443",
        TLSConfig: tlsConfig,
        Handler:   makeRouter(),
    }
}

func loadClientCertPool() *tls.CertPool {
    // In practice, load PEM data from files or environment.
    pool := tls.NewCertPool()
    // pool.AppendCertsFromPEM(...)
    return pool
}

Additionally, enforce strict validation for any header derived from request content. Use allowlists for known-safe values and avoid concatenating raw input into header values. For example, if you need to set a custom header based on a query parameter, validate against a predefined set of values and reject malformed input before assignment.
Finally, test your Chi application with tools that can send newline characters and special sequences in both certificate fields and regular request parameters to confirm that header injection is not possible. Combine these practices with the use of the middleBrick CLI to scan from terminal with middlebrick scan <url> and the GitHub Action to add API security checks to your CI/CD pipeline, ensuring continuous detection of header construction issues across deployments.