Format String in Chi with Jwt Tokens

A format string vulnerability occurs when user-controlled input is passed directly to a function that formats output, such as printf-style functions, without proper specifier validation. In the context of a Chi web application using JWT tokens, this typically arises when token payloads, headers, or claims are reflected into logs, error messages, or HTTP responses using unchecked string formatting. For example, if a route extracts a token from an Authorization header and then logs or echoes it using a formatter that does not enforce literal strings, an attacker can supply format specifiers like %s, %x, or %n to manipulate output behavior or cause crashes.

Consider a Chi handler that decodes a JWT and logs the subject claim using a format string built from user data:

(defn handler [request]
  (let [token (get-in request [:headers "authorization"])
        decoded (jwt/decode token secret)
        subject (:sub decoded)]
    (log/infof "User subject: %s" subject)  ;; Safe if %s is static
    {:status 200 :body "ok"}))

This pattern is safe because the format string is a literal. However, if the format string itself comes from an untrusted source, such as a query parameter or a manipulated claim, the same code becomes dangerous:

(defn vulnerable-handler [request]
  (let [token (get-in request [:headers "authorization"])
        decoded (jwt/decode token secret)
        fmt (get-in request [:query-params "format"])
        subject (:sub decoded)]
    (log/infof fmt subject)  ;; Unsafe if fmt is user-controlled
    {:status 200 :body "ok"}))

In this scenario, an attacker can supply ?format=%s%08x or malicious specifiers to read stack memory or cause denial of service. JWT tokens themselves do not introduce the flaw, but their presence in request processing pipelines increases the attack surface when their data is improperly formatted. Because Chi encourages concise, compositional handlers, developers may inadvertently pass dynamic values into formatting functions, especially when integrating structured logging or error reporting. The vulnerability is not in JWT parsing but in how formatted output is constructed with user-influenced strings.

Another related risk involves error messages that include token material. If an exception handler uses format-style construction to embed a JWT string in a response or log entry, and the token contains format-like sequences, the runtime may interpret them unexpectedly. For instance, a token with %x in a claim value could trigger unintended memory reads when the containing message is formatted. This is particularly relevant when middleware echoes tokens for debugging without sanitizing input. The combination of Chi's routing flexibility and JWT's base64-encoded structure, which may contain percent-encoded patterns, heightens the likelihood of accidental format injection if string construction is not disciplined.

To summarize, the vulnerability arises not from JWT handling itself, but from insecure use of formatted output where the format string is influenced by data that may originate from or be associated with JWT usage. Chi applications must ensure that any string passed to formatting functions is either statically controlled or explicitly validated, especially when dealing with dynamic request components like headers, query parameters, or parsed token claims.

Remediation focuses on ensuring that format strings are always literals and never derived from user input. In Chi, this means avoiding the direct interpolation of dynamic values into logging or error formatting functions when those values are influenced by JWT data. The safest approach is to use explicit, static format strings and pass dynamic data as arguments only.

Correct handler using a static format string:

(defn safe-handler [request]
  (let [token (get-in request [:headers "authorization"])
        decoded (jwt/decode token secret)
        subject (:sub decoded)]
    (log/infof "User subject: %s" subject)  ;; Format string is a literal
    {:status 200 :body "ok"}))

If dynamic formatting is required for legitimate reasons, validate and sanitize the format input strictly. For example, allow only a predefined set of format templates:

(def allowed-formats #{"json" "text" "brief"})

(defn controlled-handler [request]
  (let [token (get-in request [:headers "authorization"])
        decoded (jwt/decode token secret)
        fmt (get-in request [:query-params "format"])
        subject (:sub decoded)
        resolved-format (if (allowed-formats fmt) fmt "text")]
    (case resolved-format
      "json" (log/info (str "User subject: " subject))
      "text" (log/infof "User subject: %s" subject)
      "brief" (log/info (str "Subject: " subject)))
    {:status 200 :body "ok"}))

Another important practice is to avoid embedding JWT strings directly in formatted output. If logging is necessary, extract only the claims you need and use concatenation or structured logging instead of format specifiers that could be misinterpreted:

(defn no-format-handler [request]
  (let [token (get-in request [:headers "authorization"])
        decoded (jwt/decode token secret)
        subject (:sub decoded)]
    (log/info (str "User subject: " subject))  ;; No format specifiers
    {:status 200 :body "ok"}))

For middleware that processes tokens, apply the same principle: never construct format strings from token headers or claims. Instead, use fixed messages and pass token metadata as separate arguments. This approach aligns with Chi's functional, compositional style and reduces the risk of unintended interpretation of format sequences in JWT data.