Insufficient Logging in Chi with Api Keys

Chi is a lightweight HTTP router for Go commonly used to build APIs. When developers instrument Chi routes with API key validation but omit structured, detailed logging, they create an insufficient logging gap that weakens auditability and incident response. In this context, insufficient logging means the application does not reliably record who accessed which endpoint, which API key was used (or whether a key was missing/invalid), and what the outcome of the request was.

API keys are bearer credentials; they identify callers but do not carry user context. Without logging the key identifier, the route pattern, the HTTP method, the response status, and relevant timestamps, an operator cannot reliably trace a malicious request back to a particular client. For example, a request that triggers a server-side request forgery (SSRF) or an injection attempt may appear as a generic 400/500 with no key recorded, making correlation with other telemetry difficult.

Chi middleware runs before and after handlers, which gives a natural place to attach logging. If the middleware validates an API key but only returns an error without emitting a structured log line containing the key identifier (or a key ID derived from it), the event is effectively invisible to security monitoring. Attackers can probe endpoints with different keys, and if logs do not capture attempts, the defense surface remains opaque. In regulated environments, this lack of traceability can conflict with audit requirements such as PCI-DSS and SOC2, where access to API endpoints must be recorded.

Real attack patterns observed in the wild include enumeration probes where an attacker iterates through key values or formats to discover valid keys. Without logs that record each attempt along with route and outcome, detection relies on rate-limiting alerts alone. Compounded with missing input validation, this can enable SSRF or data exposure to go unnoticed if the logs do not capture the requested resource or the response size. Even when encryption is enforced, unlogged invalid key attempts provide no evidence of reconnaissance.

middleBrick scans such configurations and flags insufficient logging when audit trails are incomplete, especially around authenticated entry points like API keys. The report emphasizes adding structured logs at key validation points, capturing method, path, key identifier, and outcome, while correlating findings with OWASP API Top 10 and compliance frameworks. Note that middleBrick detects and reports these gaps but does not modify code or infrastructure.

Remediation centers on ensuring every request that involves API key validation produces a consistent, structured log entry. In Chi, this is typically done via middleware that inspects headers, validates the key, and logs relevant context before invoking the next handler.

Below is a concrete, working example using Chi and a simple key validation function. The middleware extracts the key, validates it, attaches a key identifier to the request context for downstream use, and logs structured details including route, method, outcome, and a hashed representation of the key to avoid logging raw secrets.

import (
    "context"
    "crypto/sha256"
    "encoding/hex"
    "log/slog"
    "net/http"

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

// apiKeyValidator validates the "X-API-Key" header and returns a key ID.
// In production, this would check a store or a hashed set of valid keys.
func apiKeyValidator(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        key := r.Header.Get("X-API-Key")
        route := chi.URLParam(r, "route") // if needed after routing
        method := r.Method
        path := r.URL.Path

        // Compute a non-reversible token for logging to avoid exposing the raw key.
        hashed := sha256.Sum256([]byte(key))
        keyID := hex.EncodeToString(hashed[:])

        if key == "" {
            slog.Warn("api_key_missing",
                "method", method,
                "path", path,
                "key_id", keyID,
                "outcome", "missing_key",
            )
            http.Error(w, `{"error":"missing_api_key"}`, http.StatusUnauthorized)
            return
        }

        // Replace with actual validation logic, e.g., lookup hashed key in DB.
        isValid := validateKey(key) // returns true if key is valid
        if !isValid {
            slog.Warn("api_key_invalid",
                "method", method,
                "path", path,
                "key_id", keyID,
                "outcome", "invalid_key",
            )
            http.Error(w, `{"error":"invalid_api_key"}`, http.StatusUnauthorized)
            return
        }

        // Attach key ID to context for handlers that may need it.
        ctx := context.WithValue(r.Context(), "keyID", keyID)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

// validateKey is a placeholder for actual key-checking logic.
func validateKey(key string) bool {
    // Example: constant-time comparison against stored hashes.
    // return checkAgainstStore(hashKey(key))
    return key == "valid_test_key" // simplistic for illustration only
}

func main() {
    r := chi.NewRouter()
    r.Use(middleware.RequestID)
    r.Use(middleware.Logger)
    r.Use(middleware.Recoverer)

    // Apply key validation middleware globally or per-route.
    r.Use(apiKeyValidator)

    r.Get("/health", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte(`{"status":"ok"}`))
    })

    r.Get("/data", func(w http.ResponseWriter, r *http.Request) {
        keyID := r.Context().Value("keyID")
        slog.Info("request_served",
            "path", r.URL.Path,
            "method", r.Method,
            "key_id", keyID,
            "outcome", "success",
        )
        w.Write([]byte(`{"data":"example"}`))
    })

    http.ListenAndServe(":8080", r)
}

This pattern ensures that each request logs method, path, a key identifier, and the outcome (missing, invalid, success). It avoids logging raw keys while still enabling traceability. For production, route-specific validation can be applied using r.Route groups, and logs can be enriched with request IDs and timestamps to support correlation with other systems.

middleBrick’s scans can verify that such logging is present around key validation and that findings map to relevant frameworks. The tool does not alter code but highlights gaps and provides remediation guidance consistent with these practices.