Broken Access Control in Chi with Api Keys

In Chi, a common pattern for API authentication is to pass an API key in an HTTP header such as X-API-Key. When access control is broken, this key is either missing, unused, or insufficiently scoped, allowing an unauthenticated or low-privilege caller to reach endpoints that should be limited to specific roles or tenants. Because Chi routes are typically defined once and reused across many services, a missing authorization check on one route can expose data or operations that should be isolated by user or application boundaries.

Broken Access Control with API keys becomes critical when the implementation conflates identification with authorization. For example, a route might validate that a key exists but not verify that the key grants access to the requested resource identifier, enabling BOLA/IDOR-like behavior across tenants. Similarly, keys intended for administrative functions might be accepted by non-admin routes due to inconsistent enforcement, effectively elevating privileges without requiring a distinct token. This is especially risky when combined with Chi’s tendency to compose handlers, where a public route group can inadvertently inherit relaxed middleware settings.

The vulnerability is also introduced during key provisioning and rotation. If keys are embedded in client-side code or configuration files that are broadly readable, they can be extracted and reused across projects. An attacker who discovers a single low-privilege key may attempt to leverage it across endpoints, testing whether route-level checks enforce tenant or scope boundaries. Because API keys are often long-lived compared to session tokens, a single leaked key can lead to sustained unauthorized access across multiple deployments.

Real-world attack patterns mirror findings from the OWASP API Top 10 and broader web security literature. For instance, an attacker might send crafted requests with a captured key to enumerate user IDs or resource paths, combining broken access control with insecure direct object references. In regulated environments, such weaknesses can conflict with expectations around least privilege and separation of duties, making it important for teams to treat API keys as credentials that require strict validation and scoping rather than as simple shared secrets.

middleBrick scans for these issues by testing unauthenticated and low-privilege access across routes, comparing required authorization context with actual enforcement. When API keys are used incorrectly or inconsistently, findings highlight the missing or insufficient checks and map them to compliance frameworks such as OWASP API Top 10 and SOC2. This helps teams understand not only that a route is accessible without proper authorization, but also how the misuse of API keys contributes to the risk.

Remediation focuses on ensuring every route that uses an API key validates both the presence of the key and the scope of the caller. In Chi, this is typically done by defining middleware that inspects X-API-Key, compares it against a trusted store, and attaches an authorization context to the request before reaching the handler. The following examples demonstrate a minimal, idiomatic approach that enforces key validation and role-based access within a Chi router.

import (
	"context"
	"net/http"
	"strings"

	"github.com/labstack/chi/v5"
	"github.com/labstack/chi/v5/middleware"
)

// Key represents an allowed API key and its associated roles.
type Key struct {
	Value  string
	Scopes []string
}

// In-memory trusted keys; in production, use a secure store.
var trustedKeys = map[string]Key{
	"ak_live_production": {Value: "ak_live_production", Scopes: []string{"admin", "read"}},
	"ak_live_readonly":   {Value: "ak_live_readonly", Scopes: []string{"read"}},
}

// APIKeyMiddleware validates the X-API-Key header and attaches roles to the context.
func APIKeyMiddleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		key := r.Header.Get("X-API-Key")
		if key == "" {
			http.Error(w, `{"error": "missing api key"}`, http.StatusUnauthorized)
			return
		}
		ik, ok := trustedKeys[key]
		if !ok {
			http.Error(w, `{"error": "invalid api key"}`, http.StatusUnauthorized)
			return
		}

		// Attach scopes to context for downstream use.
		ctx := context.WithValue(r.Context(), "apiScopes", ik.Scopes)
		next.ServeHTTP(w, r.WithContext(ctx))
	})
}

// RequireScopes ensures the request has at least one of the required scopes.
func RequireScopes(required []string) func(http.Handler) http.Handler {
	return func(next http.Handler) http.Handler {
		return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
			scopes, _ := r.Context().Value("apiScopes").([]string)
			for _, req := range required {
				for _, s := range scopes {
					if s == req {
						next.ServeHTTP(w, r)
						return
					}
				}
			}
			http.Error(w, `{"error": "insufficient scope"}`, http.StatusForbidden)
		})
	}
}

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

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

	// Admin route requires admin scope.
	r.Group(func(r chi.Router) {
		r.Use(RequireScopes([]string{"admin"}))
		r.Get("/admin/settings", func(w http.ResponseWriter, r *http.Request) {
			w.Write([]byte(`{"settings":{}}`))
		})
	})

	// Read-only route requires read scope.
	r.Group(func(r chi.Router) {
		r.Use(RequireScopes([]string{"read"}))
		r.Get("/data", func(w http.ResponseWriter, r *http.Request) {
			w.Write([]byte(`{"data":"public and authorized"}`))
		})
	})

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

For production, replace the in-memory map with a secure lookup service that validates keys and returns associated scopes. Always use HTTPS to prevent key interception, and rotate keys on a defined schedule. Enforce distinct scopes per key and avoid using a single key for both user and administrative operations. This pattern ensures that even if a key is leaked, its blast radius is limited by its assigned permissions.

middleBrick Pro can be integrated into your workflow to continuously monitor these controls. By adding the GitHub Action to your CI/CD pipeline, you can fail builds when routes lack required authorization checks. The CLI allows you to scan individual services from the terminal, while the Dashboard helps you track how remediation efforts affect your overall security score over time.