Insecure Direct Object Reference in Chi with Dynamodb

Insecure Direct Object Reference (IDOR) occurs when an API exposes a reference to an internal object—such as a DynamoDB item key—and allows an authenticated subject to access or modify that object without verifying authorization. In a Chi application, this typically arises when route parameters or query values are directly used to form DynamoDB request keys without confirming that the requesting user has permission to operate on the identified resource.

Consider a Chi endpoint defined as /users/:user_id/profile. If the handler extracts :user_id from the request and passes it directly to a DynamoDB GetItem or UpdateItem call, the service assumes the caller is allowed to read or update that item. The vulnerability is not in DynamoDB itself but in the application logic that skips ownership or role checks. An attacker who can obtain or guess another user’s ID can issue the same request and potentially read or modify profiles, settings, or linked data.

DynamoDB’s key schema amplifies this risk when the primary key is a predictable value like a user ID or an auto-incrementing numeric ID. Because DynamoDB does not enforce application-level permissions, the onus is on the Chi service to enforce authorization. Without explicit checks, the unauthenticated attack surface tested by middleBrick can expose IDOR: the scanner can request GET /users/123/profile while authenticated as a different user and observe whether the profile data is returned. If it is, the endpoint is vulnerable.

Another common pattern involves using a DynamoDB secondary index (GSI) to support queries such as /orgs/:org_id/resources/:resource_id. If the handler validates that the resource belongs to the organization but then uses resource_id directly in a GetItem key, an attacker who knows a valid org_id and resource_id combination could iterate over plausible IDs to access resources they should not see. middleBrick’s BOLA/IDOR checks are designed to detect such patterns by correlating spec definitions with runtime behavior, highlighting endpoints where object references are used without sufficient authorization.

In Chi, this often intersects with how request context is passed to data access modules. If the handler relies on global request parameters or session values to construct DynamoDB keys, and omits scoping by subject ID or role, the risk of IDOR increases. The use of unauthenticated scanning further exposes these gaps, because an attacker does not need valid credentials to probe whether object references are properly bounded by authorization logic.

Remediation focuses on ensuring every DynamoDB operation is scoped by authorization checks that align with the current subject. In Chi, this means explicitly validating that the resource being accessed belongs to the requesting user or the user’s organization before constructing the key expression for DynamoDB.

Below is a secure pattern for a Chi route that retrieves a user profile. The handler extracts the :user_id from the route, then confirms it matches the authenticated subject’s ID before issuing a GetItem request. The example uses the official AWS SDK for JavaScript and assumes a helper to retrieve the authenticated user ID from the request context.

;; Chi handler with proper ownership check
(require '[cheshire.core :as json]
         '[aws.sdk.dynamodb :as ddb]
         '[ring.util.response :refer [response not-found]])

(defn get-user-profile [req]
  (let [requested-user-id (get-in req [:params :user_id])
        subject-id       (get-authenticated-user-id req)] ; implementation-specific
    (if (not= requested-user-id subject-id)
      (not-found "Profile not found")
      (let [resp (ddb/get-item {:table-name "users"
                                :key       {"user_id" {:s requested-user-id}}})]
        (response (:item resp))))))

The same principle applies when working with organization-scoped resources. Before performing a Query or GetItem on a table that includes org_id as part of the key or index, the handler must ensure that the org_id in the request matches one the subject is allowed to access.

;; Secure query scoped to organization
(defn list-org-resources [req]
  (let [org-id        (get-in req [:params :org_id])
        subject-orgs  (get-authorized-org-ids req) ; returns a set or list
        org-allowed?  (contains? subject-orgs org-id)]
    (if-not org-allowed?
      (not-found "Access denied")
      (let [resp (ddb/query {:table-name "resources"
                             :index-name "gsi-org-id"
                             :key-condition-expression "org_id = :oid"
                             :expression-attribute-values {":oid" {:s org-id}}})]
        (response (:items resp)))))

When using DynamoDB with composite keys, always include the partition key in the key expression and avoid relying solely on sort key values for authorization. For example, if the table uses owner_id as the partition key and resource_id as the sort key, construct the key with both values and verify that the owner_id matches the subject’s ID or organization scope.

Additionally, prefer parameterized expressions over string concatenation to avoid accidental exposure or injection-like issues in request construction. This aligns with the input validation checks that middleBrick performs, ensuring that user-supplied values are properly validated and bounded before being used in low-level operations.

Finally, integrate these checks into your workflow by using the middleBrick CLI to scan endpoints during development: middlebrick scan <url>. For teams, the Pro plan enables continuous monitoring and GitHub Action integration so that new endpoints are automatically evaluated for IDOR and other authorization issues before deployment.