Token Leakage in Chi with Api Keys

Token leakage in a Chi application that relies on API keys typically occurs when keys are embedded in source code, configuration files, or logs, and then inadvertently exposed through client-side bundles, error messages, or version control. Chi frameworks often load configuration at runtime and may propagate headers to downstream services; if an API key is stored in a mutable configuration structure or passed through untrusted logging, an attacker who can read logs or intercept output may recover the key.

For example, consider a Chi route that adds an authorization header by reading a key from a configuration map that was intended to be server-side only:

// config.clj
(def api-config {:api-key "ak_live_12345abcdef"})

;; handler.clj
(defn wrap-api-key [handler]
  (fn [request]
    (let [api-key (:api-key (:api-config request))]
      (-> request
          (assoc-in [:headers "Authorization"] (str "Bearer " api-key))
          handler))))

If the configuration map is accidentally serialized into an HTTP response, included in debug output, or logged, the API key can be harvested. Chi applications that dynamically construct requests to third-party services are especially at risk when keys are passed through middleware that propagates headers without validation. In a black-box scan, middleBrick checks for such exposure by inspecting runtime responses and unauthenticated endpoints; findings may include references to patterns such as CWE-798 (Use of Hard-coded Credentials) and CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor).

Because API keys grant privileged access, leakage can lead to unauthorized usage, quota exhaustion, or data exfiltration. Unlike session tokens bound to a user context, API keys often have broader scope and longer lifetimes, increasing the impact of exposure. middleBrick’s LLM/AI Security checks do not apply here, but its standard 12 checks include Data Exposure and Unsafe Consumption, which help detect whether API keys appear in outputs or are mishandled in request flows.

When scanning a Chi service with middleBrick, you submit the base URL and receive a security risk score with prioritized findings. The tool correlates OpenAPI specifications (if available) with runtime behavior to highlight mismatches, such as declared authentication schemes that are not enforced. This helps you identify whether API key usage is properly constrained and whether sensitive values appear where they should not.

To remediate token leakage in Chi, ensure API keys are never embedded in code or logs, are loaded from a secure runtime source, and are strictly scoped to required operations. Use environment variables or a secrets manager available in your deployment environment, and avoid propagating keys through shared headers or mutable configuration that may be serialized.

Below is a secure pattern for loading an API key in Chi without exposing it in application state that could be logged or serialized:

;; config.clj — load from environment, no hard-coded values
(ns myapp.config
  (:require [clojure.string :as str]))

(defn load-api-key []
  (or (System/getenv "API_KEY")
      (throw (IllegalArgumentException. "API_KEY environment variable is required"))))

;; handler.clj — attach key per-request without persisting it
(ns myapp.handler
  (:require [myapp.config :refer [load-api-key]]))

(defn wrap-api-key [handler]
  (fn [request]
    (let [api-key (load-api-key)]
      (-> request
          (assoc-in [:headers "Authorization"] (str "Bearer " api-key))
          handler))))

This approach ensures the key is read at runtime and not stored in a global or request map that might be inspected later. Additionally, avoid logging the request or response in a way that includes headers:

;; Avoid logging headers that may contain sensitive values
(defn safe-logging-wrapper [handler]
  (fn [request]
    (let [response (handler request)]
      ;; Log only status and path, never full headers
      (println "Request to" (:uri request) "returned" (:status response))
      response)))

For applications that make outbound calls to third-party services, scope API keys to the minimal required permissions and rotate them regularly. In production, enforce transport-layer encryption and validate that middleware does not inadvertently pass keys to error-reporting endpoints. middleBrick’s CLI and Web Dashboard can be used to verify that keys do not appear in responses and that authentication is enforced according to your OpenAPI spec.

Integrate middleBrick into your workflow using the CLI (middlebrick scan <url>) or GitHub Action to fail builds if risky patterns are detected. The Pro plan adds continuous monitoring so that any future leakage is flagged promptly, but remember that middleBrick detects and reports — it does not modify code or block execution.