Token Leakage in Chi with Dynamodb

Token leakage in a Chi application that uses Amazon DynamoDB typically occurs when authentication or session tokens are inadvertently exposed through DynamoDB operations, logs, or responses. Chi is a lightweight HTTP router for Clojure, and when it integrates with DynamoDB—often via the AWS SDK for Java or a Clojure wrapper—misconfigured access patterns or error handling can expose sensitive tokens.

One common scenario involves storing user session tokens or API keys as item attributes in DynamoDB tables. If the application does not enforce strict attribute-level authorization, an attacker leveraging an Insecure Direct Object Reference (IDOR) or Broken Function-Level Access Control (BFLA) can enumerate or modify items to retrieve these tokens. For example, a Chi route that fetches a user profile by ID without validating ownership might return an item that contains a session_token field, unintentionally revealing credentials.

Another vector arises from DynamoDB Streams and backups. If token attributes are included in streams enabled for real-time replication or backup exports, tokens can be exposed in log streams or snapshot storage. Additionally, application logs within Chi that include raw DynamoDB responses—such as when debugging or using middleware that logs request contexts—might print items containing token fields. Without redaction, this creates a data exposure risk that maps to the Data Exposure check in middleBrick scans.

The combination is particularly risky because DynamoDB’s flexible schema allows arbitrary attributes, and Chi’s minimal routing does not inherently enforce data filtering. A scan using middleBrick’s Data Exposure and Property Authorization checks would flag unmasked token fields in responses or logs. Attack patterns like OWASP API Top 10:2023 Broken Object Level Authorization (BOLA) and excessive data exposure align with this risk. Remediation involves schema design, response filtering, and strict authorization, as detailed below.

Remediation focuses on preventing token fields from being read, returned, or logged when interacting with DynamoDB in Chi routes. Below are concrete Clojure examples using the official AWS SDK for Java (v2), integrated via integrant or similar.

1. Exclude token attributes from DynamoDB responses

Use ProjectionExpression to select only safe attributes. This ensures token fields such as access_token are never returned to the client or logged inadvertently.

(ns app.handlers
  (:require [software.amazon.awssdk.services.dynamodb :as ddb]
            [software.amazon.awssdk.services.dynamodb.model :as ddb-model]))

(defn get-user-safe
  [db-client table-name user-id]
  (let [request (ddb-model/query-request
                  {:table_name table-name
                   :key-condition-expression "user_id = :uid"
                   :expression-attribute-values {":uid" {:s user-id}}
                   :projection-expression "user_id, username, email"})]
    (.query db-client request)))

By specifying projection-expression, token attributes are omitted from the DynamoDB response, mitigating data exposure and BOLA/IDOR.

2. Enforce attribute-level authorization in Chi routes

Validate ownership before fetching items. A Chi route should confirm that the requesting user matches the item’s owner, avoiding IDOR.

(ns app.routes
  (:require [compojure.core :refer [GET PUT]]
            [ring.util.response :as resp]
            [app.db :refer [dynamodb-client table-name]]))

(defn user-handler [request]
  (let [user-id (get-in request [:session :user-id])
        item-id (get-params request "id")
        item (some-> (dynamodb-client)
                     (.query (dynamodb-model/query-request
                               {:table_name table-name
                                :key-condition-expression "id = :id AND owner_id = :owner"
                                :expression-attribute-values {":id" {:s item-id}
                                                              ":owner" {:s user-id}}})))
            :items first)]
    (if item
      (resp/response (select-keys item ["username" "email"])) ; exclude token fields
      (resp/not-found "Not found"))))

This pattern ensures that even if a token attribute exists in the DynamoDB item, it is never included in the HTTP response.

3. Redact token fields in logs and middleware

If logging DynamoDB responses, transform items to strip sensitive fields before output.

(ns app.middleware
  (:require [taoensso.timbre :as log]))

(defn sanitize-item [item]
  (dissoc item "access_token" "refresh_token" "api_key"))

(defn log-handler [handler]
  (fn [request]
    (let [response (handler request)]
      (when-let [item (:body response)]
        (log/info (str "Response: " (sanitize-item item))))
      response)))

;; Apply in Chi middleware stack
(app/use-middleware log-handler)

This prevents tokens from appearing in application logs, addressing the Data Exposure check.

4. Secure DynamoDB Streams and backups

If using streams, configure them to exclude sensitive attributes or ensure downstream consumers apply the same redaction. For backups, restrict access and audit who can view snapshot data.

middleBrick’s Data Exposure and Encryption checks can validate these configurations by scanning unauthenticated endpoints and reviewing exposed attributes.