Cors Wildcard in Chi with Dynamodb

A CORS wildcard (Access-Control-Allow-Origin: *) combined with a Chi backend that directly exposes DynamoDB operations can unintentionally grant broader access than intended. Chi is an HTTP routing library for Clojure/Clj, where route handlers often serialize query results or accept parameters that feed into DynamoDB requests. When a wildcard is used in production, any origin can invoke these endpoints and observe responses, which may include sensitive DynamoDB payloads or metadata.

Consider a Chi route that forwards a query parameter to a DynamoDB GetItem call. If CORS headers are set to *, a malicious site can make authenticated requests on behalf of users and read returned item attributes. Even if the route applies its own authorization, the wildcard removes the browser’s same-origin enforcement, allowing cross-origin reads. Attack patterns include credential leakage via Referer headers and injection of malicious origins that harvest DynamoDB responses through script tags or CORS-enabled requests.

In the context of middleBrick’s checks, this combination is flagged because the scanner detects a wildcard in Access-Control-Allow-Origin alongside an unauthenticated endpoint that interacts with DynamoDB. The scanner does not assume intent; it reports that the endpoint is accessible from any origin and may return data that should be protected. The presence of DynamoDB increases impact because responses can contain identifiers, timestamps, or configuration details useful for further attacks.

For example, a Chi route like the following illustrates the risk when paired with a wildcard CORS policy:

(require '[cheshire.core :as json]
         '[bidi.bidi :as bidi]
         '[http-kit.client :as http])

(defn dynamodb-get-handler [request]
  (let [table-name "users"
        user-id (get-in request [:params :query-string "userId"])
        ;; Direct DynamoDB call simplified for example
        url (str "https://dynamodb.region.amazonaws.com/" table-name "/" user-id)
        response @(http/get url {:headers {"Authorization" "AWS4-HMAC-SHA256 ..."}})]
    {:status 200
     :headers {"Access-Control-Allow-Origin" "*" ;; vulnerable wildcard
               "Content-Type" "application/json"}
     :body (:body response)}))

Here, the wildcard allows any site to supply a userId and read another user’s record if authorization is not enforced server-side. MiddleBrick would note the wildcard and recommend scope-limiting origins, especially when DynamoDB data is involved.

To remediate, replace the wildcard with explicit origins and enforce authorization before any DynamoDB interaction. In Chi, you can set CORS headers conditionally and validate input before constructing DynamoDB requests. The following example shows a secure handler that checks an allowlist and passes a sanitized parameter to a DynamoDB client function.

(require '[cheshire.core :as json]
         '[bidi.bidi :as bidi]
         '[http-kit.client :as http]
         '[ring.util.response :refer [response]]
         [clojure.string :as str])

(def allowed-origins #{"https://app.example.com" "https://admin.example.com"})

(defn safe-dynamodb-get-handler [request]
  (let [origin (get-in request [:headers "origin"])
        table-name "users"
        user-id (get-in request [:params :query-string "userId"])
        ;; Validate input: must be a UUID pattern
        valid-id (and (some? user-id) (re-matches #"[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}" user-id))
        allowed (contains? allowed-origins origin)]
    (if (and allowed valid-id)
      (let [url (str "https://dynamodb.region.amazonaws.com/" table-name "/" user-id)
            headers {"Authorization" "AWS4-HMAC-SHA256 ..."
                     "x-api-origin origin" origin}
            response @(http/get url {:headers headers})]
        (-> (response (:body response))
            (assoc :headers {"Access-Control-Allow-Origin" origin
                             "Content-Type" "application/json"})))
      (-> (response {:error "Forbidden"})
          (assoc :status 403 :headers {"Access-Control-Allow-Origin" (when allowed origin)})))))

This approach ensures that CORS headers reflect the actual origin, preventing arbitrary sites from reading responses. Input validation protects against malformed IDs that could cause unexpected DynamoDB behavior. For broader coverage, use the middleBrick CLI to scan endpoints and verify that no wildcard remains in production headers:

$ middlebrick scan https://api.example.com

Additionally, consider applying the Pro plan’s continuous monitoring to detect accidental wildcard re-introduction during deployments. In CI/CD, the GitHub Action can fail builds if a scan reports a CORS wildcard alongside sensitive routes.