Jwt Misconfiguration in Chi with Basic Auth

Chi is a small, fast routing library for Clojure web services. When JWT handling is combined with HTTP Basic Authentication in Chi, several misconfigurations can unintentionally expose authentication logic or weaken access control. A common pattern is to parse the Authorization header for Basic credentials and also attempt to validate a JWT from the same header or from a cookie without clearly separating the two schemes.

For example, if a developer retrieves the Authorization header and, when it starts with Basic, decodes the credentials but then also looks for a JWT in an authorization header or a token query parameter without enforcing a single, explicit authentication mechanism, the application may accept unauthenticated or partially authenticated requests. This can lead to IDOR or BOLA when the JWT is missing or invalid but the Basic credentials are present and improperly scoped.

Another specific risk is failing to validate the JWT signature or claims when a JWT is present alongside Basic credentials. Chi routes typically use middleware to transform request maps; if the JWT verification middleware is placed after route dispatching or is conditional on the presence of Basic credentials, attackers can bypass intended authorization by omitting the JWT or by relying solely on Basic credentials for endpoints that should require token-based access. This misconfiguration is particularly dangerous when combined with unauthenticated LLM endpoint detection, where an endpoint intended for authenticated users may inadvertently respond to unauthenticated probes if the JWT check is not strict.

Additionally, leaking scheme-specific details in error responses can aid attackers. If Chi responses reveal whether a JWT was malformed, expired, or missing while also exposing that Basic authentication was accepted, an attacker can enumerate valid authentication paths. Proper configuration requires explicitly choosing an authentication scheme per route or namespace and ensuring that JWT validation occurs before any business logic, with clear separation from Basic Auth checks.

Remediation centers on strict scheme separation and early validation. Define a helper to parse and verify Basic credentials against a known user store, and ensure JWT validation runs only on routes that require token authentication. Do not mix schemes within the same route unless you have explicit precedence rules.

Example: a Chi route that requires only Basic Authentication with strict credential validation:

(ns myapp.auth
  (:require [cheshire.core :as json]
            [clojure.string :as str]
            [clj-http.client :as client]
            [buddy.hashers :as hashers]))

(defn basic-credentials [request]
  (when-let [auth-header (get-in request [:headers "authorization"])]
    (when (str/starts-with? auth-header "Basic ")
      (let [encoded-token (subs auth-header 7)
            decoded (String. (clojure.core/decode-base64 encoded-token) "UTF-8")
            [user pass] (str/split decoded #":" 2)]
        {:user user :pass pass}))))

(defn validate-basic [creds]
  ;; Replace with your user store lookup; this is a strict check
  (let [valid-users {"admin" (hashers/derive "s3cr3t")}]
    (when-let [hashed-pass (get valid-users (:user creds))]
      (when (hashers/verify (:pass creds) hashed-pass)
        creds))))

(defn basic-auth-middleware [handler]
  (fn [request]
    (if-let [creds (-> request basic-credentials (validate-basic))]
      (handler (assoc request :myapp.user (:user creds)))
      {:status 401
       :headers {"WWW-Authenticate" "Basic realm=\"myapp\""}
       :body (json/generate-string {:error "Unauthorized"})})))

;; Apply to routes that require Basic Auth only
(def app
  (-> (ring/ring-handler
        (ring/router
          [(GET "/secure" request {:status 200 :body "Basic-only endpoint"})])
        {:middleware [basic-auth-middleware]})
      (basic-auth-middleware)))

Example: a Chi route that requires JWT authentication (do not rely on Basic credentials for these endpoints):
(ns myapp.auth.jwt
  (:require [cheshire.core :as json]
            [buddy.jwt :as jwt]))

(defn jwt-auth-middleware [handler]
  (fn [request]
    (if-let [token (some-> request :headers :authorization (re-find #"Bearer (.+)"))]
      (try
        (let [claims (jwt/verify token my-jwt-secret)]
          (handler (assoc request :myapp.user (:sub claims))))
        (catch Exception _
          {:status 401
           :headers {"WWW-Authenticate" "Bearer"}
           :body (json/generate-string {:error "Invalid token"})})))
      {:status 401
       :headers {"WWW-Authenticate" "Bearer"}
       :body (json/generate-string {:error "Unauthorized"})})))

;; Apply JWT middleware only to token-required routes
(def app-jwt
  (-> (ring/ring-handler
        (ring/router
          [(GET "/api/users" request {:status 200 :body "JWT-only endpoint"})])
        {:middleware [jwt-auth-middleware]})
      (jwt-auth-middleware)))

By explicitly choosing one scheme per route and validating early, you avoid ambiguous authentication states that can expose the unauthenticated attack surface and reduce risks related to IDOR and BOLA. These patterns also align with findings that may be surfaced by tools performing unauthenticated scans and LLM security checks, as they highlight where authentication boundaries are not strictly enforced.