Insufficient Logging in Chi with Dynamodb

Insufficient logging in a Chi application that uses Dynamodb can amplify both application-layer and data-layer risks. Chi is a lightweight, composable web framework for Clojure, and when request and business-layer events are not explicitly recorded, critical context about who accessed what and when is lost. This absence of structured logs makes it difficult to detect tampering, trace data exfiltration, or correlate suspicious API calls with specific identities or tokens.

Dynamodb, as a managed NoSQL store, does not provide application-level audit trails by default for every read or write. Without explicit logging in Chi handlers, you may know that a request reached your service, but you cannot reliably reconstruct which DynamoDB operations were performed, which item keys were accessed, or whether the request resulted in an unauthorized update. This gap is especially dangerous for BOLA/IDOR scenarios where an attacker iterates over identifiers and the service returns the same HTTP status regardless of whether the target item exists. An attacker can infer the existence or absence of data based on timing or subtle response differences, while defenders have no log evidence to reconstruct the sequence of item lookups.

Consider an endpoint like /users/{user-id} that performs a GetItem on a DynamoDB table keyed by PK = USER#<user-id>. If the Chi handler does not log the incoming identifier, the authenticated subject, the outcome (found/not found), and the latency, you lose visibility into enumeration attacks. Similarly, write paths that invoke PutItem or UpdateItem should log the before/after state hashes or at least the key and changed attributes; without this, you cannot detect tampering patterns such as privilege escalation through unexpected attribute updates.

Insecure defaults and missing instrumentation also mean that developers may not realize that unauthenticated LLM endpoints or verbose error messages are leaking information through side channels. If an LLM endpoint backed by DynamoDB returns detailed errors or stack traces, and those responses are not logged and monitored, attackers can probe for data patterns or configuration details. Logging should capture request metadata (method, path, authenticated subject), the minimal necessary context (key identifiers, operation type), and sanitized outcome indicators, while ensuring no PII, API keys, or executable content are written to logs.

Compliance mappings such as OWASP API Top 10 (2023) API1:2023 Broken Object Level Authorization and API2:2023 Broken User Authentication are directly relevant. SOC2 and GDPR expectations around auditability further underscore the need for traceable, immutable logs that record who accessed or modified data. middleBrick scans can surface insufficient logging findings by correlating runtime behavior with OpenAPI specs and flagging endpoints that lack observable security controls, helping teams prioritize fixes before attackers exploit the visibility gap.

Remediation centers on instrumenting Chi routes to emit structured logs for every DynamoDB interaction, ensuring each log entry captures immutable, actionable context. Use a consistent correlation ID across requests so logs from Chi handlers and downstream DynamoDB calls can be joined in SIEM or observability platforms. Below are concrete examples of how to log key operations safely in Clojure with the Chime and Amazon SDK clients.

(ns myapp.api.handlers
  (:require [cheshire.core :as json]
            [clojure.tools.logging :as log]
            [integrant.core :as ig]
            [amazonica.aws.dynamodbv2 :as ddb]))

(defn log-dynamo-op [correlation-id op table key-attrs outcome & {:keys [item error] :as extra}]
  (let [sanitized (dissoc extra :item :error) ; avoid logging raw items or stack traces
        payload (merge {:correlation_id correlation-id
                        :operation op
                        :table table
                        :key (select-keys key-attrs [:pk :sk])
                        :outcome outcome
                        :timestamp (java.time.Instant/now)} sanititized)]
    (log/info (json/generate-string payload))))

(defn get-user-handler [request]
  (let [user-id (get-in request [:path-params :user-id])
        correlation-id (or (:x-correlation-id request) (str (random-uuid)))
        pk (str "USER#" user-id)]
    (try
      (let [resp (ddb/get-item {:table-name "app-users"
                                :key {"pk" {:s pk} "sk" {:s pk}}})]
        (log-dynamo-op correlation-id "GetItem" "app-users" {:pk pk :sk pk}
                       (if (:item resp) "found" "not_found"))
        (if-let [item (:item resp)]
          {:status 200 :body (json/parse-string (json/generate-string item) true)}
          {:status 404 :body {:error "not_found"}}))
      (catch Exception e
        (log-dynamo-op correlation-id "GetItem" "app-users" {:pk pk :sk pk} "error"
                       {:error (.getMessage e)})
        (log/error e "DynamoDB error")
        {:status 500 :body {:error "internal_error"}}))))

(defn update-user-handler [request]
  (let [user-id (get-in request [:path-params :user-id])
        body (json/parse-string (:body request) true)
        correlation-id (or (:x-correlation-id request) (str (random-uuid)))
        pk (str "USER#" user-id)
        updates (select-keys body [:email :role])]
    (try
      (let [resp (ddb/update-item {:table-name "app-users"
                                   :key {"pk" {:s pk} "sk" {:s pk}}
                                   :update-expression "SET #email = :email, #role = :role"
                                   :expression-attribute-names {"#email" "email" "#role" "role"}
                                   :expression-attribute-values {":email" {:s (:email updates)}
                                                                ":role" {:s (:role updates)}}})
            changed? (not (empty? (:attributes resp)))]
        (log-dynamo-op correlation-id "UpdateItem" "app-users" {:pk pk :sk pk}
                       (if changed? "updated" "unchanged")
                       {:item (when changed? body)})
        {:status 200 :body {:status (if changed? "updated" "unchanged")}})
      (catch Exception e
        (log-dynamo-op correlation-id "UpdateItem" "app-users" {:pk pk :sk pk} "error"
                       {:error (.getMessage e)})
        (log/error e "DynamoDB update error")
        {:status 500 :body {:error "internal_error"}}))))

Key practices illustrated:

• Log operation type, table, and key attributes (pk/sk) without dumping entire items to avoid PII or secret leakage.
• Include a correlation ID that can be propagated through downstream calls, enabling traceability across Chi routes and DynamoDB calls.
• Record outcome as a categorical value (found/not_found/updated/error) rather than raw data, reducing log sensitivity while preserving auditability.
• Capture timestamps and sanitize error messages to avoid leaking stack traces or internal paths.
• Structure logs as JSON to facilitate parsing by log aggregation tools and to support automated alerting on suspicious patterns (e.g., repeated not_found for adjacent IDs).

For LLM endpoints backed by DynamoDB, ensure that inference requests and responses are also logged with sanitized prompts and outputs, excluding any PII or API keys. middleBrick can validate that your endpoints emit sufficient observability signals and map findings to frameworks like OWASP API Top 10 and compliance regimes, guiding prioritization of logging improvements without claiming to automatically remediate issues.