Bola Idor in Chi with Basic Auth

Broken Object Level Authorization (BOLA) in Chi with Basic Auth occurs when an API uses HTTP Basic Authentication to identify the caller but still exposes endpoints that operate on user-controlled identifiers without verifying that the authenticated subject is authorized to access the specific resource. Chi applications often model resources such as /accounts/{accountId} or /customers/{customerId}, and if the server resolves {accountId} from the request alone, an attacker authenticated with a low-privilege Basic Auth credential can change the ID and reach another user’s data.

With Basic Auth, the client sends an Authorization header like Authorization: Basic base64(username:password). The server typically validates the credentials and establishes an identity (e.g., a user ID or role), but if authorization checks are limited to authentication alone, the application may fail to ensure that the authenticated user owns or is permitted to operate on the requested object. For example, an authenticated user might send PATCH /accounts/1234 with an Authorization header for user alice, while the ID 1234 belongs to user bob. Without an ownership or scope check tying account 1234 to alice’s permissions, this is a BOLA flaw.

In Chi, this often maps to routes where middleware extracts user identity from the Basic Auth context and passes it through to handlers, but handlers then use request path parameters or query parameters directly to fetch and modify data. If the handler does not compare the authenticated identity against the resource’s owning user or tenant, the API leaks horizontal or vertical privilege escalation paths. Horizontal BOLA appears when one user can enumerate and manipulate other users’ records (e.g., /me/invoices/{invoiceId} where invoiceId is not scoped to the authenticated user). Vertical BOLA occurs when a lower-privilege user can perform actions reserved for administrators by tampering with IDs or leveraging predictable references.

Attackers can probe these issues with simple authenticated requests, altering numeric or UUID identifiers while keeping the same Basic Auth credentials. Because the authentication succeeds, server logs may show 200 OK responses, masking an authorization bypass. OpenAPI/Swagger specs that define securitySchemes of type http with scheme basic help document the intended use of Basic Auth, but they do not enforce object-level scoping. Runtime findings must therefore compare the authenticated subject to the resource’s ownership or tenant fields to detect BOLA in Chi endpoints.

Compounded factors in Chi include reliance on path parameters for object IDs and inconsistent middleware that applies authentication but skips authorization for certain routes. The 12 parallel security checks in middleBrick include BOLA/IDOR and Authentication, enabling detection of these mismatches. By cross-referencing the Basic Auth identity from the spec with runtime behavior, scans can highlight endpoints where authenticated access does not imply authorization on the target object, providing prioritized findings and remediation guidance rather than attempting to fix the issue automatically.

Remediation focuses on ensuring that every data access decision validates both the authenticated identity from Basic Auth and the ownership or scope of the requested object. In Chi, this typically means enriching the request context with the authenticated subject and applying checks in route handlers or middleware before querying or mutating data.

Example: a Chi endpoint for retrieving a user’s invoice by ID should compare the authenticated user identifier with the invoice’s user_id. A vulnerable pattern uses only path parameters; a fixed pattern adds an authorization guard.

// Vulnerable: no ownership check
(GET "/invoices/{invoiceId}")
let invoiceId = get-path params "invoiceId"
let invoice = db/get-invoice invoiceId
respond invoice

// Fixed: enforce ownership using authenticated user from Basic Auth
(GET "/invoices/{invoiceId}")
let invoiceId = get-path params "invoiceId"
let auth-user = get-request-context :auth-user ;; identity derived from Basic Auth
let invoice = db/get-invoice-by-id-and-user invoiceId auth-user
(if invoice
  (respond invoice)
  (respond {:error "not found"} :status 404))

Example: modifying another user’s account should be rejected by checking subject ownership before applying updates.

// Vulnerable: PATCH /accounts/{accountId} allows ID tampering
(PATCH "/accounts/{accountId}")
(let accountId (get-path params "accountId")
     body (parse-body params)
     user (get-request-context :auth-user))
;; Missing check that accountId belongs to user
(db/update-account accountId body)

// Fixed: ensure accountId maps to the authenticated user
(PATCH "/accounts/{accountId}")
(let accountId (get-path params "accountId")
     body (parse-body params)
     user (get-request-context :auth-user))
(if (db/account-belongs-to-user? accountId user)
  (db/update-account accountId body)
  (respond {:error "unauthorized"} :status 403))

On the infrastructure side, Basic Auth credentials should be validated against a user store, and the resulting identity must be attached to the request map used by Chi handlers. Middleware can set :auth-user, and handlers must consistently use this value to scope queries. Avoid using only role claims for object-level decisions; prefer explicit ownership or tenant identifiers stored alongside resources.

middleBrick scans can surface these issues by comparing the authenticated subject defined in the Basic Auth security scheme with the runtime behavior of endpoints that accept object identifiers. Findings include the specific endpoint, the missing scope check, and remediation guidance, helping teams tighten authorization without disrupting existing authentication flows.