Api Key Exposure in Chi (Go)

Chi is a lightweight, idiomatic router for building HTTP services in Go. When API keys are passed via headers, query parameters, or cookies through Chi routes, improper handling can lead to Api Key Exposure. This occurs when keys are logged, echoed in error responses, or transmitted without adequate transport protections. Because Chi does not enforce transport security by itself, developers must explicitly ensure keys are never reflected in responses or server logs.

In a black-box scan, middleBrick tests unauthenticated endpoints to detect whether API keys are inadvertently exposed in responses (for example, returned in JSON bodies or error messages). A common pattern in Chi is to read a key from request headers and forward it to downstream services; if the handler inadvertently includes the key in a debug log or response body, the scan flags this as Data Exposure. MiddleBrick also checks whether keys appear in URLs via query parameters, which can be recorded in server logs or browser history, increasing leakage risk.

Middleware configurations in Chi can inadvertently expose keys if developers use custom handlers that copy headers into responses or log full request headers. For instance, a middleware that logs all incoming headers for debugging may print API keys to stdout or a log aggregation service. Because scans run in 5–15 seconds and include checks for Data Exposure and Unsafe Consumption, middleBrick can identify whether API keys are reflected in responses or logged during the scan window.

Additionally, if an endpoint accepts an API key in a query string (e.g., /proxy?key=SECRET) and passes it to another service without redaction, middleBrick may flag this as a potential BFLA or Privilege Escalation risk if the key influences authorization boundaries. The scanner cross-references OpenAPI specs, if provided, against runtime behavior to detect mismatches where a key-bearing parameter is documented but should be restricted.

Using middleBrick’s CLI, you can scan a Chi service to surface these issues without setup: middlebrick scan https://api.example.com. The report provides prioritized findings with severity and remediation guidance, mapping issues to frameworks like OWASP API Top 10 and compliance standards.

Remediation focuses on preventing API keys from appearing in responses, logs, or URLs, and ensuring they are handled only in secure server-side contexts. The following examples demonstrate secure patterns in Chi handlers and middleware.

1. Avoid echoing API keys in responses or logs

Never include raw API keys in log entries or HTTP responses. Instead, use structured logging that redacts sensitive values. The example below shows a Chi middleware that sanitizes headers before logging.

import (
	"log"
	"net/http"

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

func sanitizeHeaders(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		// Copy headers for safe inspection, excluding sensitive keys
		hdrs := make(http.Header)
		for k, vv := range r.Header {
			if k == "Authorization" || k == "X-API-Key" {
				hdrs.Set(k, "[REDACTED]")
			} else {
				hdrs[k] = vv
			}
		}
		log.Printf("Incoming request: %s %s headers: %v", r.Method, r.URL.Path, hdrs)
		next.ServeHTTP(w, r)
	})
}

func proxyHandler(w http.ResponseWriter, r *http.Request) {
	apiKey := r.Header.Get("X-API-Key")
	if apiKey == "" {
		http.Error(w, "missing key", http.StatusBadRequest)
		return
	}
	// Use apiKey server-side only; do not write it to the response
	resp, err := http.Get("https://upstream.example.com/data")
	if err != nil {
		http.Error(w, "upstream error", http.StatusBadGateway)
		return
	}
	defer resp.Body.Close()
	// Forward response body without exposing the key
	w.WriteHeader(resp.StatusCode)
	// io.Copy or similar to stream body
}

func main() {
	r := chi.NewRouter()
	r.Use(middleware.RequestID)
	r.Use(middleware.RealIP)
	r.Use(sanitizeHeaders)
	r.Get("/proxy", proxyHandler)
	http.ListenAndServe(":8080", r)
}

2. Use secure header propagation and avoid query parameters for keys

Prefer Authorization headers over query parameters to minimize logging and referrer leakage. If you must pass keys via headers, ensure downstream clients do not inadvertently expose them.

func authMiddleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		key := r.Header.Get("Authorization")
		if key == "" {
			http.Error(w, "unauthorized", http.StatusUnauthorized)
			return
		}
		// Validate key server-side without reflecting it
		if !isValidKey(key) {
			http.Error(w, "forbidden", http.StatusForbidden)
			return
		}
		next.ServeHTTP(w, r)
	})
}

func isValidKey(key string) bool {
	// Validate against a secure store or constant-time comparison
	return key == "REDACTED_VALID_KEY_PLACEHOLDER"
}

3. Enforce HTTPS and secure transport

Chi does not enforce TLS, so configure your server to use HTTPS and avoid transmitting keys over insecure channels. In production, terminate TLS at the load balancer or use Go’s http.Server with TLS settings.

import "crypto/tls"

srv := &http.Server{
	Addr: ":8443",
	TLSConfig: &tls.Config{
		MinVersion: tls.VersionTLS12,
	},
}

middleBrick’s scans validate Transport Encryption as a separate check; ensuring TLS and avoiding key reflection will improve your security score. For ongoing monitoring, the Pro plan provides continuous scanning and alerts when exposures are detected.