Cryptographic Failures in Chi with Jwt Tokens

Chi, a functional web framework for Clojure, is commonly used to build HTTP APIs that rely on JWT tokens for authentication and authorization. When cryptographic controls are weak, JWT tokens can be forged, tampered with, or exposed, leading to account takeover or privilege escalation. A cryptographic failure in this context means the application fails to properly validate token integrity, uses weak algorithms, or mishandles secrets, allowing an attacker to bypass intended access controls.

One common pattern is accepting unsigned tokens or tokens with the none algorithm. If a Chi endpoint does not explicitly enforce an algorithm, an attacker can supply a header like {"alg": "none"} and a valid-looking payload, and the server may treat it as trusted. Another failure is using symmetric keys incorrectly—for example, using the same key for signing and verification across multiple services, or embedding secrets in client-side JavaScript where they can be extracted. Poor random generation for secrets, or storing signing keys in environment variables without rotation, also weakens cryptographic integrity. These weaknesses map to the broader OWASP API Top 10 category of Cryptographic Failures and can intersect with BOLA/IDOR when token claims are not strictly validated per resource ownership.

Insecure JWT handling can also lead to data exposure. If a JWT contains sensitive claims (such as roles, scopes, or user identifiers) and is transmitted over non-HTTPS endpoints, an attacker performing network interception can read or modify the token. Even when HTTPS is used, failing to validate standard claims like iss (issuer), aud (audience), and exp (expiration) can allow replay attacks or use of tokens across environments. MiddleBrick’s scans include checks for weak algorithms, missing validation, and exposure of tokens in logs or error messages, highlighting risks specific to Chi-based APIs that use JWT tokens without strict cryptographic hygiene.

Remediation focuses on strict validation, strong algorithms, and secure key management. Always specify the expected algorithm and reject tokens using none. Use asymmetric cryptography where possible, verifying signatures with a public key rather than a shared secret. Ensure all token claims are validated, and enforce HTTPS for all token transmission. The following examples show secure patterns in Chi using the buddy-sign library, which is commonly used for JWT operations in Clojure ecosystems.

First, define a secure token verification function that explicitly sets the algorithm and validates claims:

(ns myapp.auth
  (:require [buddy.sign.jwt :as jwt]
            [buddy.core.codecs :as codecs]))

(defn verify-token [token public-key]
  (try
    (jwt/verify token public-key {:alg :rs256
                                  :verify-exp true
                                  :verify-iss true
                                  :expected-iss "my-auth-server"
                                  :verify-aud true
                                  :expected-aud "my-api-audience"})
    (catch Exception e
      (throw (ex-info "Invalid token" {:type ::invalid-token})))))

Second, when issuing tokens, avoid weak keys and specify strong algorithms:

(ns myapp.auth
  (:require [buddy.sign.jwt :as jwt]
            [buddy.core.keys :as keys]
            [buddy.core.codecs :as codecs]))

(defn generate-token [user-claims private-key]
  (jwt/sign (merge user-claims {:exp (System/currentTimeMillis) :iss "my-auth-server" :aud "my-api-audience"})
            private-key
            {:alg :rs256}))

Third, integrate verification into a Chi handler, ensuring tokens are validated before processing requests:

(ns myapp.routes.api
  (:require [compojure.core :refer [GET POST defroutes]]
            [myapp.auth :refer [verify-token]]
            [ring.util.http-response :refer :all]))

(defn authenticated-handler [handler public-key]
  (fn [request]
    (let [token (some-> request :headers (get "authorization") (clojure.string/replace-first "Bearer " ""))]
      (if token
        (let [claims (verify-token token public-key)]
          (handler (assoc request :claims claims)))
        (unauthorized "Missing or invalid token")))))

(defroutes api-routes
  (GET "/profile" [] {:status 200 :body "profile data"})
  (route/not-found "Not found"))

(def app
  (-> api-routes
      (authenticated-handler (keys/public-key-from-pem (slurp "/path/to/public.pem")))))

These examples enforce algorithm restrictions, claim validation, and proper key handling, reducing the risk of cryptographic failures. For teams using the Pro plan, continuous monitoring can alert you to insecure JWT configurations as your API evolves, while the CLI allows you to test endpoints directly from the terminal with middlebrick scan <url>. The GitHub Action can fail builds if risky token handling is detected, and the MCP Server enables rapid scanning from within your IDE when writing Chi-based authentication code.