Jwt Misconfiguration in Chi with Jwt Tokens

Chi is a minimalistic web framework for Clojure that does not enforce authentication by default. When developers integrate Jwt Tokens for protecting routes, misconfigurations commonly expose the unauthenticated attack surface that middleBrick scans as part of its Authentication and BOLA/IDOR checks. A typical vulnerability arises when routes that return sensitive data or administrative functions are not explicitly guarded, allowing an attacker to call them with a missing, malformed, or unsigned Jwt Token.

In practice, a developer might wrap routes using a middleware helper but omit validation of the token’s signature, issuer, or audience. For example, using the cheshire library to decode a token without verifying its cryptographic signature means any string can be interpreted as a valid identity. middleBrick’s unauthenticated scan can exercise these endpoints and detect that no Authentication check was enforced, resulting in a finding with severity High under the Authentication category.

Another common pattern in Chi is relying on route parameters as identifiers without checking ownership or authorization. If an endpoint like /api/users/:id returns user details but does not ensure that the subject of the Jwt Token matches the :id, this becomes an Insecure Direct Object Reference (IDOR), which middleBrick flags under BOLA/IDOR. Because Chi does not provide built-in authorization, developers must explicitly compare claims in the token payload with the resource being accessed. Failure to do so results in a per-category breakdown that includes Property Authorization and BOLA/IDOR, with prioritized findings that include severity and remediation guidance.

Additionally, tokens with overly permissive scopes or roles can lead to Privilege Escalation if Chi endpoints do not enforce role-based access controls at the handler level. A misconfigured Jwt Token that contains an admin claim may be accepted by a handler that should be restricted to standard users. middleBrick tests these scenarios by probing unauthenticated and low-privilege contexts, checking whether endpoints inadvertently expose privileged operations without proper checks. The scanner’s 12 security checks run in parallel, ensuring that weaknesses in Authentication, Property Authorization, and BOLA/IDOR are surfaced quickly without requiring credentials.

Because Chi applications often rely on third-party libraries for Jwt handling, subtle issues such as weak algorithms (e.g., none) or missing expiration validation can be introduced. middleBrick’s Authentication checks include testing for tokens that do not require verification and endpoints that accept unsigned tokens. When such patterns are detected, the report includes severity, a description, and remediation steps, helping developers align with OWASP API Top 10 and related compliance frameworks.

To remediate Jwt Misconfiguration in Chi, enforce signature verification, validate standard claims, and apply route-level authorization checks. Below are concrete code examples that demonstrate a secure pattern using the cheshire and buddy-sign libraries for token parsing and verification.

First, define a function that verifies the Jwt Token and extracts claims. This example uses buddy-sign to validate the signature with a public key and checks the exp (expiration) and iss (issuer) claims:

(ns myapp.auth
  (:require [buddy.sign.jwt :as jwt]
            [cheshire.core :as json]
            [ring.util.response :refer [response unauthorized]]))

(defn verify-token [token public-key]
  (try
    (jwt/unsign token public-key {:alg :rs256})
    (catch Exception _
      nil)))

(defn get-claims [token public-key]
  (when-let [verified (verify-token token public-key)]
    (try
      (json/parse-string verified true)
      (catch Exception _
        nil))))

Next, create an authorization middleware that ensures a valid token exists and that the subject matches the requested resource. For a route like /api/users/:id, compare the sub claim from the token with the :id path parameter:

(defn auth-middleware [handler public-key]
  (fn [request]
    (let [token (get-in request [:headers "authorization"])
          claims (get-claims token public-key)]
      (if-not claims
        (unauthorized "Invalid or missing token")
        (if-not (= (:sub claims) (get-in request [:params :id]))
          (unauthorized "Insufficient permissions")
          (handler request))))))

Apply this middleware to protected routes in your Chi application:

(def app
  (-> (routes
        (GET "/api/users/:id" [] ...)
        (POST "/api/admin" ...))
      (auth-middleware public-key)))

For endpoints that require role-based access, inspect the roles or scope claims and enforce restrictions at the handler or via a separate authorization function. This ensures that a token with administrative privileges cannot inadvertently access user-specific endpoints without explicit checks, reducing the risk detected by middleBrick’s BOLA/IDOR and Privilege Escalation tests.

When using the CLI tool, you can run middlebrick scan <url> to validate that your endpoints now require authentication and that tokens are properly validated. The dashboard and reports available in the Pro plan can help track improvements over time, while the GitHub Action can enforce a minimum security score before merging changes.