Ssrf in Chi with Jwt Tokens

Server-Side Request Forgery (SSRF) in a Chi application that handles JWT tokens can occur when an endpoint that validates or forwards requests based on a JWT token makes outbound HTTP calls to user-supplied URLs. If the application does not restrict or sanitize these URLs, an attacker can coerce the server into making requests to internal services, metadata endpoints, or other protected resources, potentially exfiltrating data embedded in JWT tokens or leveraging internal network reachability.

In Chi, this often manifests when a route accepts a URL parameter or header (for example, a redirect or webhook target) and uses an HTTP client to call that URL while also inspecting or propagating JWT token claims. Because the server-side request is not properly constrained, an attacker can supply an internal address such as http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS instance metadata) or internal Kubernetes services, bypassing network-level isolation. If the JWT token is included in the forwarded request headers or used to authorize the call, sensitive token contents or roles may be exposed or abused through the SSRF vector.

The interaction between SSRF and JWT tokens becomes critical when token introspection or validation is performed by an external service reachable via user input. For example, an attacker might supply a malicious target URL that causes the server to fetch and return the contents of a JWT verification endpoint, inadvertently exposing validation logic or key material if logs or error responses are not carefully controlled. This can amplify information disclosure beyond what a standard SSRF might reveal.

middleBrick detects SSRF as part of its 12 parallel security checks and can identify endpoints in Chi services where user-influenced destinations interact with JWT handling. By scanning unauthenticated attack surfaces, it surfaces risky routes and provides remediation guidance to help prevent token-related data exposure through SSRF paths.

To mitigate SSRF risks in Chi when working with JWT tokens, ensure that any outbound HTTP requests are constructed from safe, pre-defined targets and that user input never directly specifies the request destination. Validate and restrict destinations before using them with an HTTP client, and avoid forwarding JWT tokens to untrusted endpoints.

Example: Unsafe route with user-supplied URL

;; UNSAFE: user can control target URL, SSRF risk
(defn unsafe-handler [request]
  (let [target (get-in request [:query-params :url])
        token (some-get request :jwt-token)]
    (if-let [resp (http/get target {:headers {"Authorization" (str "Bearer " token)}})]
      {:status 200 :body (:body resp)}
      {:status 500 :body "fetch failed"})))

Example: Safe route with controlled destinations

;; SAFE: destination is enumerated and validated; JWT used only for authorization
(defn safe-handler [request]
  (let [allowed-destinations {"service-a" "https://api.internal.example.com/a"
                              "service-b" "https://api.internal.example.com/b"}
        destination-name (get-in request [:query-params :service])
        token (some-get request :jwt-token)]
    (if-not (contains? allowed-destinations destination-name)
      {:status 400 :body "invalid service"}
      (let [target (allowed-destinations destination-name)
            resp (http/get target {:headers {"Authorization" (str "Bearer " token)}}
                           {:timeout 5000})]
        {:status 200 :body (:body resp)}))))

Example: Validating and encoding URLs to prevent SSRF

;; SAFE: validate host against a denylist, enforce HTTPS, do not forward tokens to arbitrary endpoints
(defn validate-url [url]
  (when-let [parsed (some--> url java.net.URL.)]  
    (let [host (.getHost parsed)]
      (when-not (or (.startsWith host "169.254.")
                    (.startsWith host "127.")
                    (.contains host "internal.metadata"))
        (when (.startsWith (.getScheme parsed) "https")
          url)))))

(defn handler-with-validation [request]
  (let [raw-url (get-in request [:query-params :target])
        safe-url (validate-url raw-url)]
    (if-not safe-url
      {:status 400 :body "invalid target"}
      (let [resp (http/get safe-url {:timeout 5000})
            token (some-get request :jwt-token)]
        ;; Use token only as a bearer credential for the intended destination
        {:status 200 :body (:body resp)}))))

Principles to follow

• Never use user-controlled input as the request target for outbound HTTP calls.
• Whitelist or strictly validate destinations; avoid open redirects or dynamic host resolution.
• Do not propagate JWT tokens to endpoints that are not explicitly required and verified.
• Enforce timeouts and avoid following unexpected redirects when fetching user-provided URLs.

By combining input validation and strict destination control, Chi services can safely use JWT tokens for authorization without introducing SSRF risks. middleBrick can highlight routes where user input influences outbound requests and JWT handling, supporting remediation aligned with frameworks such as OWASP API Top 10 and SOC2.