Session Fixation in Chi with Api Keys

Session fixation in the context of Chi web applications that rely on API keys for authentication occurs when an application assigns a known session identifier before a user authenticates, and that identifier is not replaced after successful API-key validation. Chi is a functional, compositional web framework for Clojure that encourages explicit request handling, but developers must still manage session and authentication state securely.

Consider a scenario where a Chi handler sets a session cookie (or a custom header used as a session token) with a static or predictable value at the start of interaction, then later accepts an API key provided by the client (e.g., via header) to determine authorization. If the handler does not rotate or bind the session to the authenticated principal, an attacker can fixate the session identifier by persuading a victim to use a known session ID and then, after the victim authenticates with a valid API key, the server treats the fixed ID as trusted.

For example, if an endpoint uses middleware that sets a session ID early and later calls a function like (assoc-in request.session [:api-key] provided-key) without invalidating the prior session linkage, the server may treat the fixed session as proof of authentication. This becomes a cross-site request forgery (CSRF) aid or a direct bypass if the API key is treated as a session credential and the session identifier is predictable or not regenerated.

Because API keys are typically long-lived secrets compared to session cookies, fixation here can be more severe: an attacker can hard-code a victim’s API key into a URL or script and rely on the server’s lax session handling to execute authenticated actions on behalf of the victim. The risk is especially relevant when API keys are passed in headers and the framework’s session store is not properly isolated from unauthenticated request paths.

In Chi, this maps to the Authentication and BOLA/IDOR checks performed by middleBrick. A scanner testing the unauthenticated attack surface can detect whether session identifiers are set before key validation and whether key rotation or session regeneration occurs after successful authentication.

Remediation focuses on ensuring that session state and API key usage are strictly separated and that session identifiers are regenerated after authentication. Do not treat API keys as session identifiers; instead, use them as bearer credentials validated on each request while keeping session identifiers ephemeral.

Example secure Chi handler that avoids fixation by not binding a session identifier to an API key and by rotating session state after authentication:

(ns myapp.handlers
  (:require [ring.util.http-response :refer [ok unauthorized]]
            [ring.middleware.session :as session]))

(defn login-handler [request]
  (let [provided-key (get-in request [:headers "x-api-key"])
        valid-key? (valid-api-key? provided-key)]
    (if valid-key?
      ;; Do NOT store API key in session; return a fresh session ID via Set-Cookie
      (let [response (ok {:status "authenticated"})
            new-session (session/session request {:authenticated true})]
        (assoc response :session new-session))
      (unauthorized {:error "invalid-key"}))))

(defn protected-handler [request]
  (let [api-key (get-in request [:headers "x-api-key"])]
    (if (valid-api-key? api-key)
      (ok {:data "secure-resource"})
      (unauthorized {:error "missing-or-invalid-key}))))

(defn valid-api-key? [key]
  ;; Constant-time comparison to avoid timing attacks
  (some? (and key (not= key "") (re-find #"^hk_live_[A-Za-z0-9]+$" (str key)))))

If you use session middleware, ensure that session creation happens only after successful validation and that prior session data is not reused. Avoid patterns that set session values before authentication, such as:

(defn insecure-handler [request]
  ;; Anti-pattern: session set before API key validated
  (let [sess (session/session request {:pre-set "value"})
        key (get-in request [:headers "x-api-key"])]
    (if (valid-api-key? key)
      (assoc-in sess [:api-key] key) ;; Do not mutate session with key
      (unauthorized {}))))

Additionally, configure your API gateway or load balancer to rotate or suppress exposed session identifiers when API keys are used, and ensure that endpoints requiring API keys do not rely on cookie-based session fixation defenses alone. middleBrick’s checks for Authentication and BOLA/IDOR will surface whether session identifiers persist across authentication events.