Cors Wildcard in Chi with Cockroachdb

A CORS wildcard (Access-Control-Allow-Origin: *) in a Chi application that communicates with Cockroachdb can unintentionally expose backend behavior and data when credentials or sensitive response details are involved. Chi routes are often composed with fine-grained endpoint-specific policies, and if a wildcard is applied at a high level or mistakenly attached to authenticated routes, the browser will accept responses for cross-origin requests even when the frontend origin is not explicitly trusted.

When your Chi service issues SQL queries directly to Cockroachdb, the HTTP response may include headers, cookies, or custom headers that reflect database metadata or application state. A wildcard prevents the browser from enforcing origin-based access control, so any site on the internet can make requests to your endpoint and read the response if credentials are included. This becomes a Cross-Site Request Forgery (CSRF) aid or a data leakage channel when combined with per-user data from Cockroachdb.

Chi applications using middleware to set CORS headers must ensure that the wildcard is never used together with credentials. For example, if you set Access-Control-Allow-Credentials: true alongside Access-Control-Allow-Origin: *, the browser will reject the response in secure contexts, but misconfiguration can lead to inconsistent behavior across browsers. Additionally, preflight requests may reveal allowed methods and headers, giving an attacker insight into the backend integration with Cockroachdb.

Consider the following incorrect Chi configuration in Clojure:

(defn wrap-cors-misconfigured [handler]
  (let [cors-headers {"Access-Control-Allow-Origin" "*"
                      "Access-Control-Allow-Credentials" "true"
                      "Access-Control-Allow-Methods" "GET,POST,OPTIONS"
                      "Access-Control-Allow-Headers" "Content-Type,Authorization"}]
    (fn [request]
      (let [response (handler request)]
        (update-in response [:headers] merge cors-headers)))))

In this setup, the combination of * and credentials makes the endpoint non-compliant with browser security policies and can lead to inconsistent or overly permissive cross-origin access to data retrieved from Cockroachdb. An authenticated frontend on a malicious site could leverage this to perform unauthorized reads if other defenses are missing.

To avoid this, explicitly list trusted origins and conditionally set CORS headers based on the request origin. This prevents information exposure via HTTP responses that include user-specific data from Cockroachdb and reduces the attack surface for CSRF and data exfiltration scenarios.

Remediation focuses on replacing the wildcard with explicit origin checks while preserving necessary functionality for your frontend applications. In Chi, you typically implement CORS as a middleware layer that inspects the request origin and conditionally adds headers only when the origin is allowed.

The following example shows a safe CORS middleware for Chi that works with Cockroachdb-backed routes. It maintains support for credentials and limits origins to a predefined allowlist:

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

(defn wrap-cors-safe [handler]
  (let [cors-headers-fn (fn [request headers]
                         (let [origin (get-in request [:headers "origin"])]
                           (cond-> {"Access-Control-Allow-Methods" "GET,POST,OPTIONS"
                                    "Access-Control-Allow-Headers" "Content-Type,Authorization"
                                    "Access-Control-Allow-Credentials" "true"}
                             (and origin (contains? allowed-origins origin))
                             (assoc "Access-Control-Allow-Origin" origin))))]
    (fn [request]
      (let [response (handler request)
            cors-headers (cors-headers-fn request (:headers response))]
        (update-in response [:headers] merge cors-headers)))))

This approach ensures that responses containing data from Cockroachdb are only exposed to known frontend origins. The middleware reads the origin header from the request and compares it against a set of trusted origins. If there is no match, the CORS headers do not include an Access-Control-Allow-Origin entry, causing the browser to block the frontend from reading the response.

For deployments where frontend origins may vary (e.g., multiple subdomains or environments), you can make the allowlist dynamic by reading from configuration or environment variables. Here is an example that uses an environment variable ALLOWED_ORIGINS split by commas:

(def allowed-origins
  (into #{} (map str/trim) (str/split (System/getenv "ALLOWED_ORIGINS") #",")))

By combining explicit origin validation with careful header management, you protect endpoints that query Cockroachdb from unintended cross-origin access while maintaining compatibility with legitimate clients. This aligns with secure defaults recommended for applications that expose database-backed HTTP services.