Vulnerable Components in Chi with Dynamodb

Chi is a functional, type-safe routing library for Clojure web applications. When used with Amazon DynamoDB, several patterns common in Chi services can expose components to security risks, particularly around data access control and input handling. The combination often leads to insecure direct object references (IDOR) and insufficient authorization checks at the database layer.

In Chi, route handlers are typically composed as middleware that extract parameters from the request and pass them directly to downstream functions. If those functions construct DynamoDB queries using unchecked user input—such as an :id from a path parameter—without validating ownership or context, the handler may retrieve or modify records that belong to other users. For example, a handler like /users/:id/profile that uses the :id in a DynamoDB query key condition without verifying that the authenticated subject owns that ID results in a BOLA/IDOR flaw.

Chi handlers commonly use libraries like integrant or component-based constructors to manage DynamoDB clients. If the client configuration embines shared credentials or broad IAM permissions, a single exposed endpoint can lead to wide-ranging data exposure. Additionally, when response data from DynamoDB is serialized directly into JSON for API replies, sensitive attributes such as internal state flags or administrative roles may be included if field-level filtering is not enforced.

The lack of schema validation on incoming query or body parameters in Chi routes compounds the issue. Without explicit checks, an attacker can supply unexpected keys or nested structures that alter the semantics of a DynamoDB condition expression, potentially bypassing intended filters. For instance, providing a FilterExpression fragment in a JSON payload could change which items are returned, leading to unauthorized data enumeration.

DynamoDB’s pagination model also introduces risks when Chi endpoints iterate through results without enforcing a maximum limit. An unbounded query that scans large datasets can expose more records than intended, increasing data exposure. In combination with weak or missing rate limiting, this can facilitate reconnaissance or low-volume scraping of sensitive information through repeated calls.

Finally, logging practices in Chi applications that include raw DynamoDB request parameters can inadvertently leak sensitive data into centralized logging systems. If log streams are not properly guarded, API keys, personal identifiers, or token values included in query arguments may persist in log retention stores, creating a long-term data exposure vector.

Remediation focuses on strict input validation, explicit ownership checks, and controlled serialization. Always treat path and query parameters as untrusted and validate them before constructing any DynamoDB expression.

Example: Safe Parameter Handling and Ownership Check

(ns myapp.handler.user
  (:require [cheshire.core :as json]
            [aws.sdk.dynamodb :as ddb]
            [ring.util.response :as resp]))

(defn get-user-profile
  "Retrieve profile only if the requesting user owns the record."
  [{{user-id :user-id} :session
    path-params :params}
   dynamodb-client]
  (let [target-id (get path-params "id")
        ;; Validate format to prevent injection via malformed keys
        validated-id (when (re-matches #"^[a-f0-9-]{36}$" target-id)
                       target-id)]
    (if (not= user-id validated-id)
      (resp/response {:error "Unauthorized"})
      (try
        (let [response (ddb/get-item dynamodb-client
                                     {:table-name "users"
                                      :key {:user-id validated-id}})
              item (:item response)]
          (resp/response (select-keys item [:user-id :display-name :email])))
        (catch Exception e
          (resp/response {:error "Not found"})))))))

Example: Parameterized FilterExpression with Whitelisted Fields

(ns myapp.handler.search
  (:require [aws.sdk.dynamodb :as ddb]
            [ring.util.response :as resp]))

(defn search-items
  "Search with explicit field projection and owner filter."
  [{{user-id :user-id} :session query-params :params}
   dynamodb-client]
  (let [status (get query-params "status")
        allowed-statuses #{"active" "pending"}
        projection-expr "id, title, status"
        owner-filter "ownerId = :uid"]
    (when-not (contains? allowed-statuses status)
      (resp/response {:error "Invalid status"}))
    (let [response (ddb/query dynamodb-client
                              {:table-name "items"
                               :index-name "status-index"
                               :key-condition-expression "status = :statusval"
                               :filter-expression owner-filter
                               :expression-attribute-values {":statusval" status
                                                            ":uid" user-id}
                               :projection-expression projection-expr})]
      (resp/response (:items response))))))

Remediation Practices Summary

• Validate and sanitize all path, query, and body inputs before using them in DynamoDB expressions.
• Enforce ownership checks at the handler level; never rely solely on database-level permissions.
• Use projection expressions to limit returned fields and avoid exposing sensitive attributes.
• Implement reasonable pagination limits and avoid full table scans in production handlers.
• Scrub logs to ensure raw parameter values, especially keys, are not written to observability systems.