Null Pointer Dereference in Chi with Jwt Tokens

A null pointer dereference in a Chi application that uses JWT tokens typically occurs when the code attempts to access a property or method on a token-parsing result that is null or None. This can happen when a JWT is missing, malformed, or fails validation, yet the handler proceeds to use the token payload as if it were a valid object.

In Chi, routes are composed as a series of middleware and handlers. If JWT validation is implemented as a custom middleware that extracts the token from headers, decodes it, and attaches the payload to the request, a missing or invalid token may result in a null payload being attached. Subsequent handlers that assume the payload exists may then attempt to access fields such as subject or roles, leading to a runtime exception.

Consider the following scenario: a JWT middleware decodes the token but returns null when the token is invalid. The route then pattern-matches on the payload without checking for nullity:

(defn auth-middleware [handler]
  (fn [request]
    (let [token (some/extract-token request)
          payload (some/decode token)] ; returns nil if invalid
      (handler (assoc request :identity payload)))))

(defn profile-handler [request]
  (let [user-id (:sub (:identity request))] ; potential NPE if :identity is nil
    {:status 200 :body (str "User " user-id)}))

;; Route definition
(def app
  (r/router
    [(auth-middleware profile-handler)]))

If a request without a valid JWT reaches profile-handler, :identity will be null, and accessing :sub will cause a null pointer dereference. This exposes an application crash or an internal server error, which may reveal stack traces or aid in further exploitation.

The interaction with JWT tokens amplifies the risk because token handling often involves multiple conditional checks (expiration, signature, issuer). Skipping any of these checks before accessing token claims can introduce null pointer vulnerabilities. This is especially true when using libraries that return optional types or nullable objects for failed parsing.

From a security perspective, this is a crash-level issue rather than a direct data breach, but it can lead to denial of service or information leakage. In the context of middleBrick scans, this would typically appear under the Input Validation and Authentication checks, flagged as a potential crash vector when unauthenticated endpoints are tested.

To prevent null pointer dereference when using JWT tokens in Chi, ensure that token decoding results are explicitly checked before use. Use some or when-let to safely handle optional values, and return an appropriate HTTP response when the token is invalid or missing.

Here is a safe pattern using some to decode and validate the token before proceeding:

(defn safe-auth-middleware [handler]
  (fn [request]
    (if-let [token (some/extract-token request)
             :let [payload (some/decode token)]
             :when (some? payload)]
      (handler (assoc request :identity payload))
      {:status 401 :body "Unauthorized"})))

(defn safe-profile-handler [request]
  (if-let [user-id (get-in request [:identity :sub])]
    {:status 200 :body (str "User " user-id)}
    {:status 401 :body "Invalid token"}))

;; Route definition with safe middleware
(def app
  (r/router
    [(safe-auth-middleware safe-profile-handler)]))

In this example, some/decode is expected to return either a valid map or null. The middleware checks for the presence of a payload using some? and short-circuits with a 401 response if it is missing. The handler then uses get-in to safely navigate the nested map, avoiding any direct dereference of potentially null values.

Another approach is to use when-let for clearer intent when the logic requires multiple steps:

(defn when-let-profile [request]
  (when-let [token (some/extract-token request)]
    (when-let [payload (some/decode token)]
      (let [user-id (:sub payload)]
        {:status 200 :body (str "User " user-id)}))))

(defn handler-with-when [request]
  (or (when-let-profile request)
      {:status 401 :body "Missing or invalid token"}))

These patterns ensure that JWT token handling is robust against missing or malformed input. They align with best practices for functional error handling in Clojure and integrate naturally with Chi’s composable middleware architecture.

When using middleBrick, these fixes would help improve scores in the Authentication and Input Validation categories, as the scanner looks for proper handling of unauthenticated states and unsafe object access. The tool can detect whether endpoints properly guard against missing tokens and whether responses avoid exposing internal errors.