Log Injection in Chi with Mutual Tls

Log injection occurs when untrusted input is written directly into application or system logs without proper sanitization. In the Chi web framework for Go, this typically arises through user-controlled fields such as request paths, headers, or query parameters that are later included in structured or plain-text logs. When mutual TLS (mTLS) is enforced, the server requests and validates client certificates, which introduces additional metadata—such as the Common Name (CN) or Organizational Unit (OU) from the client certificate—into the request context. If this metadata is logged naively, it can become an injection vector.

Consider a Chi middleware that extracts the client certificate from the TLS connection and writes the subject to the access log:

import (
	"crypto/tls"
	"net/http"
	"github.com/go-chi/chi/v5"
)

func certSubject(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		if tlsState := r.TLS; tlsState != nil && len(tlsState.PeerCertificates) > 0 {
			// Potential log injection point: subject may contain newlines or special chars
			subject := tlsState.PeerCertificates[0].Subject.String()
			// Unsafe: directly concatenating untrusted data into logs
			http.Error(w, "OK", http.StatusOK)
		}
	})
}

func main() {
	r := chi.NewRouter()
	r.Use(certSubject)
	r.Get("/", func(w http.ResponseWriter, r *http.Request) {
		w.Write([]byte("ok"))
	})
	http.ListenAndTLS(":8443", tlsConfig)
}

If an attacker can present a certificate with a subject containing newline characters (e.g., CN=attacker X509v3 extensions:), the log entry can be polluted with additional lines, potentially forging log context or obscuring real events. This becomes especially dangerous when logs are ingested by monitoring tools that parse line-based formats. The combination of mTLS and structured logging can inadvertently amplify the impact: certificate fields that seem safe (like CN) may contain carriage returns or other control characters, and logging them without validation enables log injection. Moreover, if logs include request-scoped identifiers derived from certificate fields (e.g., serial number or SANs), an attacker might inject false identifiers, complicating forensic analysis.

middleBrick detects such risks by scanning unauthenticated attack surfaces and flagging uncontrolled use of request context data in logging paths. Its findings map to OWASP API Top 10 categories and reference concrete patterns like CVE-adjacent injection techniques, helping teams understand how benign logging practices can be subverted when mTLS metadata enters the log stream.

Remediation focuses on sanitizing and validating any data derived from the TLS connection before it reaches logging or any downstream processing. For Chi, this means wrapping handlers or middleware to normalize certificate fields and enforce strict allow-lists for characters that may appear in logs.

Safe logging practice: extract only necessary, validated fields and encode or truncate them. For example, use a sanitized subject string that removes control characters and avoids concatenation with log format strings that could be misinterpreted:

import (
	"crypto/tls"
	"fmt"
	"net/http"
	"regexp"
	"strings"
	"github.com/go-chi/chi/v5"
)

var cleanSubject = regexp.MustCompile(`[^A-Za-z0-9@._-]`)

func safeCertSubject(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		if tlsState := r.TLS; tlsState != nil && len(tlsState.PeerCertificates) > 0 {
			subject := tlsState.PeerCertificates[0].Subject.String()
			// Remove control characters and non-alphanumeric chars except @._-
			sanitized := cleanSubject.ReplaceAllString(subject, "_")
			// Optionally limit length to avoid log flooding
			if len(sanitized) > 128 {
				sanitized = sanitized[:128]
			}
			// Safe: sanitized value written to structured logs
			_ = sanitized
			http.Error(w, "OK", http.StatusOK)
		}
	})
}

func main() {
	r := chi.NewRouter()
	r.Use(safeCertSubject)
	r.Get("/", func(w http.ResponseWriter, r *http.Request) {
		w.Write([]byte("ok"))
	})
	http.ListenAndServeTLS(":8443", "server.crt", "server.key", r)
}

When using the middleBrick CLI (middlebrick scan <url>) or the GitHub Action to integrate API security checks into CI/CD pipelines, teams can validate that their endpoints do not leak sensitive certificate fields in logs or responses. For continuous monitoring, the Pro plan allows scheduled scans and alerts if risky patterns are detected across API changes.

Additionally, ensure that any certificate metadata stored in structured logs follows a consistent schema and does not rely on free-form strings. Using explicit field names and avoiding dynamic concatenation reduces the likelihood of injection breaking log parsers. The MCP Server can be used to scan APIs directly from development environments, catching such issues before they reach production.