Missing Authentication in Chi with Api Keys

Chi is a lightweight HTTP router for Go commonly used to build APIs. When developers configure routes without enforcing authentication, or when they rely solely on API keys but do not validate the key on each request, the API exposes an unauthenticated attack surface. middleBrick scans this unauthenticated surface and can detect endpoints that accept requests without a valid API key, returning a security risk finding for Missing Authentication.

An API key is a bearer credential: possession of the key is assumed to be proof of identity. If a Chi route is defined without a middleware that checks the presence and validity of an API key, any remote attacker can send requests directly to the endpoint. In a black-box scan, middleBrick tests unauthenticated paths and checks whether sensitive operations or data are accessible without credentials. For API-key-protected endpoints, this includes verifying that every expected route rejects requests missing the key or an invalid key.

Common implementation mistakes that lead to Missing Authentication in Chi include omitting the auth middleware for selected routes, registering the middleware after routes (so it does not apply), or using a configuration where the API key is read from an environment variable but not validated against a trusted source on each request. Another pattern is using the key only for initial health checks or admin routes while leaving user-facing endpoints unprotected. Because Chi does not enforce authentication by default, it is the developer’s responsibility to explicitly apply key validation. middleBrick’s checks align with OWASP API Top 10 A01: Broken Object Level Authorization, often arising when authentication is missing or inconsistently applied.

During a scan, middleBrick may detect Missing Authentication when unauthenticated requests succeed with a 200 status code or when information disclosure occurs (e.g., verbose errors or metadata) without providing an API key. Findings include the endpoint path, the HTTP method, and a description of the missing protection. This detection is not an assumption about intent; it is an observation of runtime behavior when no authentication guard is present. For API-key schemes, the scan verifies whether requests with missing keys are accepted, and whether keys passed in headers, query parameters, or cookies are validated correctly.

Remediation guidance centers on ensuring every route that handles sensitive operations requires a valid API key and that validation occurs in a consistent, centralized location. Developers should implement Chi middleware that inspects the expected key location (commonly an Authorization header) and rejects requests with 401 Unauthorized when the key is missing or invalid. The middleware should short-circuit the request chain to prevent downstream handlers from executing. Because API keys are bearer tokens, they must be treated as secrets; avoid logging them and prefer transmitting them over TLS.

To fix Missing Authentication in Chi, implement a reusable middleware that validates API keys on every request. Below is a complete, syntactically correct example showing route definitions protected by API-key validation, including how to read the expected key from configuration and how to reject invalid requests.

// main.go
package main

import (
	"fmt"
	"log"
	"net/http"
	"os"

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

// apiKeyMiddleware validates the presence and correctness of an API key.
// The expected key is read from the environment for better security and configurability.
func apiKeyMiddleware(expectedKey string) func(http.Handler) http.Handler {
	return func(next http.Handler) http.Handler {
		return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
			// Prefer the Authorization: Bearer  header for API keys.
			key := r.Header.Get("Authorization")
			const bearerPrefix = "Bearer "
			if len(key) == len(bearerPrefix) || key[:len(bearerPrefix)] != bearerPrefix {
				http.Error(w, `{"error":"unauthorized","message":"missing or invalid Authorization header"}`, http.StatusUnauthorized)
				return
			}
			key = key[len(bearerPrefix):]
			if key != expectedKey {
				http.Error(w, `{"error":"unauthorized","message":"invalid API key"}`, http.StatusUnauthorized)
				return
			}
			next.ServeHTTP(w, r)
		})
	}
}

// readAPIKey retrieves the API key from environment variables and ensures it is set.
func readAPIKey() string {
	key := os.Getenv("API_KEY")
	if key == "" {
		log.Fatal("API_KEY environment variable is required")
	}
	return key
}

func userHandler(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintf(w, `{"data":"user profile"}`)
}

func adminHandler(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintf(w, `{"data":"admin dashboard"}`)
}

func main() {
	expectedKey := readAPIKey()

	r := chi.NewRouter()
	r.Use(middleware.Logger)

	// Apply API key protection globally.
	r.Use(apiKeyMiddleware(expectedKey))

	// Public or unauthenticated endpoints can be selectively excluded by using a middleware override,
	// for example by wrapping specific routes in a subrouter without the key middleware.
	r.Get("/health", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, `{"status":"ok"}`)
	})

	// Protected routes
	r.Get("/user", userHandler)
	r.Get("/admin", adminHandler)

	// Example of a route with parameters that still requires the API key
	r.Get("/items/{id}", func(w http.ResponseWriter, r *http.Request) {
		id := chi.URLParam(r, "id")
		fmt.Fprintf(w, `{"id":"%s","data":"item details"}`, id)
	})

	log.Println("Server starting on :8080")
	log.Fatal(http.ListenAndServe(":8080", r))
}

In this example, apiKeyMiddleware checks for a Bearer-prefixed API key in the Authorization header and returns 401 with a JSON error if the key is missing or incorrect. The expected key is sourced from an environment variable, avoiding hardcoded secrets. For endpoints that should remain public (like health checks), you can either start the router with the middleware and exclude specific paths via subrouters, or conditionally skip validation within a handler based on route patterns.

Alternatively, if you prefer to pass the API key as a query parameter (less recommended due to logging risks), you can adapt the middleware to read r.URL.Query().Get("key") and validate accordingly. Ensure that the validation logic is centralized to avoid inconsistent protection across routes. middleBrick’s scans can verify that such validation is present and that unauthenticated requests are rejected, helping you confirm that Missing Authentication is resolved.