Identification Failures in Chi with Dynamodb

Identification failures occur when an application cannot reliably assert the identity of a request or the intended target of an operation. In the context of Chi and Amazon DynamoDB, this typically maps to the BOLA (Broken Object Level Authorization) / IDOR category checked by middleBrick. Chi is a lightweight HTTP routing library for Clojure, and DynamoDB is a managed NoSQL store; the combination can expose identification weaknesses when authorization checks are incomplete, ambiguous, or incorrectly tied to the data key.

One common pattern is using a DynamoDB primary key that embeds a user identifier (e.g., PK = "USER#123", SK = "PROFILE#self") and then allowing a Chi route to fetch an item by a client-supplied ID without reconfirming that the ID matches the authenticated subject. Because DynamoDB does not enforce ownership, the server must enforce it. If the route handler resolves the ID from the path, performs a GetItem, and returns the item without verifying that the authenticated subject matches the partition key or a controlling attribute, an attacker can enumerate or manipulate IDs to access other users’ objects.

With DynamoDB, identification failures also arise from how partition/sort keys are interpreted. A Chi handler might accept an id query parameter or path segment and directly use it as the Key without normalizing or namespacing it. For example, an ID like 123 could map to a different logical entity depending on the partition key design, and without a consistent mapping strategy, the same numeric ID may resolve to different items across user contexts. This lack of deterministic mapping enables horizontal privilege escalation: an attacker iterates through plausible IDs and observes which return data they are allowed to see or modify.

middleBrick’s BOLA/IDOR checks highlight these risks by correlating runtime requests with the OpenAPI schema and observed authorization gaps. When a Chi endpoint exposes a DynamoDB key as a user-controlled identifier without enforcing subject linkage, the scan flags an identification failure. This can manifest as missing ownership checks, ambiguous key construction, or over-permissive read/write permissions on items that should be constrained to the authenticated user or tenant. Proper identification in this stack requires tying every DynamoDB operation to the authenticated identity, validating that the item’s key components reflect that identity, and ensuring responses do not leak identifiers that should be opaque to the client.

Real-world attack patterns include enumeration via sequential IDs, tampering with path parameters to reference another user’s DynamoDB key, or exploiting missing tenant discriminators in composite keys. These are cataloged in the OWASP API Security Top 10 and can lead to unauthorized data access or manipulation. By combining Chi routing with DynamoDB’s key-based model, developers must explicitly encode identification guarantees in handlers rather than relying on the database to enforce them.

Remediation centers on ensuring that every DynamoDB operation is bound to the authenticated subject and that identifiers are constructed and validated deterministically. Below are concrete code examples using the AWS SDK for JavaScript v3 and common Chi routing patterns.

1. Enforce ownership by encoding user identity in the key

Instead of accepting a raw ID from the client, derive the DynamoDB key from the authenticated subject. This prevents IDOR by design.

(require '[aws.sdk.dynamodb :as d]
         '[cheshire.core :as json]
         '[ring.util.response :as resp])

(defn get-profile [request]
  (let [user-uuid (:sub (:identity request)) ; authenticated subject
        key {:PK (str "USER#" user-uuid)
             :SK "PROFILE#self"}
        {:keys [Item] :as out} @(d/get-item {:table-name "AppTable"
                                             :key key})]
    (if Item
      (resp/response (json/generate-string Item))
      (resp/response-json {:error "not-found"} {:status 404}))))

2. Validate client-supplied IDs against the authenticated subject

If you must accept an ID, map it to the subject and verify consistency before issuing any DynamoDB operation.

(defn resolve-entity-id [client-id user-uuid]
  (str user-uuid "#" client-id))

(defn update-profile [request]
  (let [user-uuid (:sub (:identity request))
        client-id (:id (:params request))
        expected-pk (resolve-entity-id client-id user-uuid)
        key {:PK expected-pk
             :SK (str "ENTITY#" client-id)}
        body (json/parse-string (:body request) true)
        {:keys [Item] :as out} @(d/update-item {:table-name "AppTable"
                                                :key key
                                                :update-expression "set #data = :d"
                                                :expression-attribute-names {"#data" "data"}
                                                :expression-attribute-values {":d" (:data body)
                                                                             :updated-at (js/Date.now)}})]
    (if Item
      (resp/response-json {:ok true})
      (resp/response-json {:error "forbidden"} {:status 403}))))

3. Use composite keys with tenant or subject discriminators

Design your DynamoDB schema so that the partition key includes the subject or tenant, and never rely solely on a client-provided value.

(defn list-user-items [request]
  (let [user-uuid (:sub (:identity request))
        pk (str "USER#" user-uuid)
        sk-prefix "ITEM#"
        query-key {:PK pk
                   :SK (str sk-prefix "*")}
        {:keys [Items] :as out} @(d/query {:table-name "AppTable"
                                           :key-condition-expression "PK = :pk AND begins_with(SK, :skprefix)"
                                           :expression-attribute-values {":pk" pk
                                                                        ":skprefix" sk-prefix}})
        items (map #(dissoc % :PK :SK) Items)]
    (resp/response-json items)))

4. Avoid exposing raw keys in URLs and opaque identifiers

Use a mapping layer or UUIDs that are resolved server-side. If you expose a key component in a URL, ensure it cannot be trivially enumerated or linked to another user’s data.

(defn safe-handler [request]
  (let [user-uuid (:sub (:identity request))
        token-id (get-token-from-params request) ; validated server-side
        key {:PK (str "TOKEN#" token-id)
             :SK (str "USER#" user-uuid)}
        {:keys [Item] :as out} @(d/get-item {:table-name "AppTable" :key key})]
    (if (and Item (= (:user-uuid Item) user-uuid))
      (resp/response-json Item)
      (resp/response-json {:error "forbidden"} {:status 403}))))

5. Enforce least-privilege IAM and conditional checks

Ensure the credentials used by Chi have permissions scoped to the subject’s resources. Combine IAM policies with application-level checks for defense in depth.

(defn authorized-query? [user-uuid pk]
  (and (some? pk)
       (str/starts-with? pk (str "USER#" user-uuid))))

(defn handler [request]
  (let [user-uuid (:sub (:identity request))
        pk (:pk (parse-query (:query request)))
        key {:PK pk :SK (:sk (parse-query (:query request)))}
        _ (when-not (authorized-query? user-uuid (:PK key))
            (throw (ex-info "Unauthorized" {:status 403})))
        {:keys [Item] :as out} @(d/get-item {:table-name "AppTable" :key key})]
    (if Item
      (resp/response Item)
      (resp/response-json {:error "not-authorized"} {:status 403}))))

By anchoring DynamoDB operations to the authenticated identity, validating keys server-side, and designing schemas with ownership constraints, you mitigate identification failures in Chi applications. These practices align with the remediation guidance available through middleBrick scans, which can surface such issues during automated assessments.