Missing Tls in Chi with Jwt Tokens

Transport Layer Security (TLS) ensures confidentiality and integrity for HTTP traffic. When a Chi-based API endpoint does not enforce TLS, any data exchanged—including JWT tokens—can be observed or altered in transit. JWTs are often used for stateless authentication and authorization; they are typically transmitted in the Authorization header as a bearer token. If the service is reachable over HTTP, an on-path attacker can intercept these tokens, leading to token theft, session hijacking, or impersonation.

Chi is a functional routing library for Clojure web applications. A common misconfiguration is exposing a Chi handler on HTTP while it issues or validates JWTs, without redirecting to HTTPS or requiring TLS at the server/load balancer level. Because JWTs often contain identity claims and may not be encrypted themselves (they are typically signed, not encrypted), intercepting them reveals user identity and permissions. This becomes critical when applications mistakenly embed sensitive information in the JWT payload, relying only on signature integrity while neglecting transport protection.

Another subtle risk involves service-to-service communication: internal Chi services that accept JWTs over HTTP within a supposedly trusted network may inadvertently allow token leakage if logs or monitoring capture Authorization headers. The scanner category Data Exposure can detect such endpoints during an unauthenticated scan. Additionally, weak or missing TLS can enable downgrade attacks where a client is tricked into using an insecure connection, making signature validation irrelevant if the token never reaches the server securely.

Remediation focuses on enforcing TLS and ensuring JWTs are only transmitted over secure channels. Below are concrete examples for a Chi application using the buddy-sign library for JWT handling.

Enforce HTTPS in Chi routes

Use middleware to reject or redirect non-TLS requests before they reach handlers that issue or validate JWTs.

(ns myapp.core
  (:require [compojure.core :refer [defroutes GET]]
            [compojure.route :as route]
            [hiccup.core :refer [html]]
            [buddy.sign.jwt :as jwt]))

(defn secure-only-handler [request]
  (if (= (:server-port request) 443)
    {:status 200 :body "OK"}
    {:status 301 :headers {"Location" (str "https://" (:server-name request) (:request-uri request))}
     :body "Redirecting to HTTPS"}))

(defroutes app-routes
  (GET "/login" [] (login-form))
  (GET "/callback" [] callback-handler)
  (route/not-found "Not Found"))

(def app
  (-> app-routes
      (wrap-defaults site-defaults)
      (wrap-secure-only))) ;; custom middleware ensuring TLS

JWT issuance and validation over HTTPS

When issuing a JWT, ensure the token is handed to the client only when the request arrived over HTTPS. Similarly, when validating tokens, prefer checking the token binding to the channel’s TLS properties where available.

(ns myapp.auth
  (:require [buddy.sign.jwt :as jwt]
            [ring.util.response :as resp]))

(def secret-key "s3cr3t-k3y-3n0ugh-l3ngth")

(defn issue-token [user-map request]
  (if (= (:scheme request) :https)
    (let [token (jwt/sign {:sub (:uid user-map) :role (:role user-map)} secret-key)]
      (resp/response {:token token}))
    (resp/response {:error "Use HTTPS to obtain a token"} :status 403)))

(defn validate-token [request]
  (let [token (some-> request :headers (get "authorization"))
        claims (jwt/unsign token secret-key {:alg :hs256})]
    (if claims
      {:status 200 :body (str "Authenticated as " (:sub claims))}
      {:status 401 :body "Invalid token"})))

Server-level TLS enforcement

In production, enforce TLS at the proxy or load balancer in front of Chi. Configure your server to redirect HTTP to HTTPS and to require valid certificates for all API endpoints, especially those handling JWTs.

# Example Nginx snippet
server {
    listen 80;
    server_name api.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    ssl_certificate /etc/ssl/certs/api.example.com.crt;
    ssl_certificate_key /etc/ssl/private/api.example.com.key;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Authorization $http_authorization;
    }
}