HIGH cors wildcardchibasic auth

Cors Wildcard in Chi with Basic Auth

Cors Wildcard in Chi with Basic Auth — how this specific combination creates or exposes the vulnerability

Chi is a Clojure web framework where routes are typically organized as a nested map of HTTP methods and paths. When developing with Chi, it is common to use a CORS middleware that includes an :allow-origins setting. Setting that value to a wildcard string "*" allows any origin to make cross-origin requests. This is convenient during development but becomes a security risk when combined with Basic Authentication.

Basic Authentication relies on the Authorization header containing the scheme Basic followed by a base64-encoded username:password string. Browsers include credentials—specifically cookies and HTTP authentication—in cross-origin requests when the CORS configuration allows credentials. If a Chi application sets :allow-credentials true alongside a wildcard origin, the browser will send the Basic Auth credentials to any site that can make a request to your endpoint. This effectively bypasses the protection that Basic Auth provides, because the credentials are transmitted to any origin that can trigger a cross-origin request.

The specific vulnerability pattern involves three interacting conditions:

  1. The server responds with Access-Control-Allow-Origin: *.
  2. The server responds with Access-Control-Allow-Credentials: true.
  3. The request includes the Authorization: Basic ... header.

Under these conditions, a malicious site can craft a cross-origin request (for example using fetch or an img tag for simple requests, or an XMLHttpRequest/fetch with custom headers for preflighted requests). The browser will include the Basic Auth credentials, and the attacker can observe the response, effectively stealing the credentials over a cross-origin context. This maps to the OWASP API Top 10 category Broken Object Level Authorization (BOLA) and Security Misconfiguration, because the wildcard CORS policy improperly exposes authenticated endpoints.

Chi applications that parse the Authorization header manually or via middleware must ensure that CORS is not permissive when authentication is required. The framework does not automatically prevent this misconfiguration; it is the developer’s responsibility to align CORS settings with the authentication model. Scans performed by middleBrick can detect a wildcard Access-Control-Allow-Origin in combination with authentication headers, highlighting the risk of credential exposure across origins.

Additionally, because Basic Auth sends credentials on every request, a wildcard CORS policy can lead to unauthorized origins making authenticated requests without the user’s knowledge. This is especially dangerous when the API also exposes sensitive data or administrative endpoints. MiddleBrick’s checks for CORS misconfiguration alongside authentication mechanisms help identify this specific attack surface, and its OpenAPI/Swagger analysis can cross-reference declared CORS settings with runtime behavior to confirm whether credentials are at risk.

Basic Auth-Specific Remediation in Chi — concrete code fixes

To remediate the combination of CORS wildcard and Basic Auth in Chi, you should restrict origins explicitly, conditionally apply CORS headers, and avoid sending credentials to untrusted origins. Below are concrete, syntactically correct examples that demonstrate secure configurations.

1. Explicit origin allowlist with credentials

Instead of using a wildcard, define a list of trusted origins and reflect the Origin header when it matches. Include credentials only for those origins.

(ns myapp.core
  (:require [cheshire.core :as json]
            [ring.util.response :as resp]))

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

(defn cors-middleware [handler]
  (fn [request]
    (let [origin (get-in request [:headers "origin"])
          allowed? (contains? (allowed-origins) origin)]
      (if allowed?
        (let [response (handler request)]
          (-> response
              (resp/header "Access-Control-Allow-Origin" origin)
              (resp/header "Access-Control-Allow-Credentials" "true")
              (resp/header "Access-Control-Allow-Headers" "Authorization, Content-Type")))
        (handler request)))))

;; Apply the middleware to your Chi routes
(def app
  (-> routes
      cors-middleware))

2. Conditional CORS with Basic Auth header presence

Only include CORS headers that expose credentials when the request actually contains an Authorization header. This reduces the surface area for requests that do not require authentication.

(defn cors-middleware-auth-aware [handler]
  (fn [request]
    (let [auth-header (get-in request [:headers "authorization"])
          origin (get-in request [:headers "origin"])
          allowed? (and auth-header (some #(= origin (str "https://" %)) ["api.example.com" "app.example.com"]))]
      (let [response (handler request)]
        (if allowed?
          (-> response
              (resp/header "Access-Control-Allow-Origin" origin)
              (resp/header "Access-Control-Allow-Credentials" "true"))
          response)))))

3. Chi route-level configuration for authenticated endpoints

For endpoints that require Basic Auth, explicitly set CORS headers per route rather than globally. This ensures that public endpoints can remain open while authenticated endpoints are protected.

(defn auth-basic [request]
  (let [auth-header (get-in request [:headers "authorization"])
        [scheme credentials] (when auth-header (clojure.string/split auth-header #"\\s+" 2))
        valid? (and (= scheme "Basic") (valid-credentials? credentials))]
    (if valid?
      {:status 200 :body (json/generate-string {:message "Authenticated"})}
      {:status 401 :body (json/generate-string {:error "Unauthorized"})})))

(def app
  (-> (merge public-routes
             {"/admin" {:get (cors-middleware-auth-aware auth-basic)}})
      (wrap-defaults site-defaults)))

4. Reject wildcard origins when credentials are present

Ensure your CORS logic does not reflect a wildcard origin when the request includes an Authorization header. Refuse the request or return a strict origin policy.

(defn strict-cors-middleware [handler]
  (fn [request]
    (let [origin (get-in request [:headers "origin"])
          auth (get-in request [:headers "authorization"])]
      (if (and auth (not= origin "*"))
        (let [response (handler request)]
          (-> response
              (resp/header "Access-Control-Allow-Origin" origin)
              (resp/header "Access-Control-Allow-Credentials" "true")))
        (handler request)))))

These examples demonstrate how to align CORS configuration with Basic Authentication in Chi. By replacing wildcard origins with an allowlist and conditionally setting headers, you prevent credentials from being exposed cross-origin. middleBrick can validate these configurations by scanning your API endpoints and confirming that Access-Control-Allow-Origin is not * when authentication is required.

Related CWEs: dataExposure

CWE IDNameSeverity
CWE-200Exposure of Sensitive Information HIGH
CWE-209Error Information Disclosure MEDIUM
CWE-213Exposure of Sensitive Information Due to Incompatible Policies HIGH
CWE-215Insertion of Sensitive Information Into Debugging Code MEDIUM
CWE-312Cleartext Storage of Sensitive Information HIGH
CWE-359Exposure of Private Personal Information (PII) HIGH
CWE-522Insufficiently Protected Credentials CRITICAL
CWE-532Insertion of Sensitive Information into Log File MEDIUM
CWE-538Insertion of Sensitive Information into Externally-Accessible File HIGH
CWE-540Inclusion of Sensitive Information in Source Code HIGH

Frequently Asked Questions

Why is using Access-Control-Allow-Origin: * with Basic Auth dangerous?
Because Basic Auth credentials are sent automatically by browsers in cross-origin requests when credentials are allowed. A wildcard origin permits any site to trigger such requests, exposing credentials to attackers.
How can middleBrick help detect CORS misconfigurations with authentication?
middleBrick scans your API endpoints and checks for a wildcard Access-Control-Allow-Origin header in combination with authentication mechanisms like the Authorization header, highlighting the risk of credential exposure across origins.