Bola Idor in Chi with Mutual Tls

Business Logic Authorization (BOLA) and Insecure Direct Object References (IDOR) in Chi with Mutual TLS (mTLS) can occur when authentication is enforced via client certificates, but authorization is still performed using user-controlled identifiers without validating the relationship between the authenticated identity and the requested resource.

Mutual TLS provides strong authentication at the transport layer by verifying client certificates. In a Chi application, this typically means the certificate information is available in the request context. However, if the handler then uses an ID from the URL or query parameters (such as /users/:id/resource/:resource_id) without confirming that the authenticated principal is allowed to access that specific ID, an IDOR/BOLA flaw exists. The attacker presents a valid client certificate for an account they control, but manipulates the resource identifier to access another user’s data.

For example, suppose a Chi route is defined as:

(defroutes app-routes
  (GET "/api/users/:user-id/profile" request
    (let [client-cert (get-in request [:ssl-client-cert :subject])]
      (response/json (get-user-profile (:user-id request))))))

Here, :user-id comes from the path, while the certificate only proves the caller is a valid client. If the certificate maps to user alice but the request is /api/users/bob-id/profile, the server may return Bob’s profile if it does not enforce that the authenticated user matches the requested user ID. This is an IDOR protected only by mTLS, not by proper ownership checks.

The risk is compounded in microservice and API gateway setups where mTLS terminates at the edge and the downstream service assumes the identity has been fully validated. Without explicit checks tying the certificate’s identity (e.g., subject, serial, or a mapped user ID) to the resource identifier, the authorization boundary is effectively missing. Attackers can leverage this to enumerate IDs (user IDs, order IDs, document IDs) and access or modify data across tenant boundaries.

middleBrick detects this pattern by correlating the unauthenticated attack surface findings with the OpenAPI spec and runtime inputs. Even when mTLS is used for authentication, if the spec or runtime behavior allows ID manipulation without ownership validation, a BOLA/IDOR finding is raised with severity and remediation guidance mapped to OWASP API Top 10 and related compliance frameworks.

To fix IDOR/BOLA in Chi when mTLS is used, you must enforce that the authenticated principal derived from the client certificate can only access resources they own or are explicitly permitted to access. Do not rely on mTLS alone for authorization.

First, extract and map the client certificate to an application user or role. Then, ensure every handler that accesses a resource by ID compares that ID against the authenticated principal’s allowed set. Below is a concrete Chi example that demonstrates this pattern.

(ns myapp.core
  (:require [cheshire.core :as json]
            [compojure.core :refer [GET defroutes]]
            [compojure.route :as route]
            [ring.util.response :refer [response]]))

;; Assume a function that maps certificate subject to a user record
(defn get-user-by-cert [cert-subject]
  ;; In practice, look up by subject or mapped attribute
  (db/find-user-by-identity cert-subject))

(defn authorize-user-for-profile! [user-id request]
  (let [client-cert (get-in request [:ssl-client-cert :subject])
        mapped-user (get-user-by-cert client-cert)]
    (when (not= user-id (:id mapped-user))
      (throw (ex-info "Unauthorized" {:status 403 :message "BOLA/IDOR violation"})))))

(defroutes app-routes
  (GET "/api/users/:user-id/profile" request
    (let [user-id (Long/parseLong (:user-id (:path-params request)))]
      (authorize-user-for-profile! user-id request)
      (response (db/get-profile user-id))))
  (route/not-found "Not Found"))

This pattern ensures that the resource ID from the path is explicitly checked against the identity derived from the certificate. If they don’t match, a 403 is returned, preventing IDOR.

For APIs that involve nested resources, extend the check to ownership or scoped permissions. For example, checking that an authenticated user can only access their own orders:

(defn authorize-order-access! [order-id request]
  (let [client-cert (get-in request [:ssl-client-cert :subject])
        user (get-user-by-cert client-cert)]
    (when-not (db/order-belongs-to-user? order-id (:id user))
      (throw (ex-info "Forbidden" {:status 403})))))

(defroutes app-routes
  (GET "/api/users/:user-id/orders/:order-id" request
    (let [order-id (Long/parseLong (:order-id (:path-params request)))]
      (authorize-order-access! order-id request)
      (response (db/get-order order-id)))))

In production, combine this with centralized policy checks or allowlists derived from the certificate metadata. middleBrick’s Pro plan supports continuous monitoring for such authorization misconfigurations, scanning your Chi endpoints and flagging routes where resource identifiers are not properly constrained by authenticated identity. You can integrate these checks into CI/CD with the GitHub Action to fail builds if BOLA/IDOR patterns are detected, and use the MCP Server to scan APIs directly from your IDE during development.