Bola Idor in Actix with Api Keys

Broken Object Level Authorization (BOLA) occurs when an API exposes an object identifier (such as a resource ID) without verifying that the requesting actor has permission to access that specific object. In Actix-based services that rely on API keys for authentication, BOLA can emerge when keys are treated as a global credential that grants broad access, rather than as a scoped credential tied to a specific tenant or user context.

Consider an endpoint like GET /organizations/{org_id}/members/{member_id}. If the Actix handler only validates the presence and validity of an API key (e.g., via an extractor that checks a key store) and then directly uses org_id and member_id in a database query without confirming the key is authorized for that org_id, an attacker can modify the URL parameters to access or manipulate other organizations’ members. Because the API key is often long-lived and stored in client-side code or configuration files, it becomes easy to pivot across organizations.

This pattern is common when developers implement authentication at the middleware level (verifying the key) but skip object-level authorization within the handler. The attack surface is unauthenticated from the scanner’s perspective if the key is provided, but from an attacker’s viewpoint, a valid key obtained through leakage or weak storage enables horizontal privilege escalation across resources that should be isolated by organization or tenant boundaries. The risk is compounded when the response reveals details about other resources, confirming the existence of BOLA.

In the context of middleBrick’s checks, this maps to the BOLA/IDOR category and intersects with the Authentication and Property Authorization checks. The scanner tests whether changing identifiers while keeping the same API key leads to unauthorized data access, highlighting gaps in per-request authorization logic rather than simple authentication failures.

Remediation centers on ensuring that every access to an object includes an authorization check that ties the API key to the specific object or tenant. Do not rely on the key alone to enforce object ownership. Below are concrete Actix examples that demonstrate a vulnerable pattern and a corrected pattern.

Vulnerable pattern

use actix_web::{web, HttpResponse, Responder};
use serde::{Deserialize, Serialize};

#[derive(Deserialize)]
struct Params {
    org_id: String,
    member_id: String,
}

async fn get_member_info(params: web::Query<Params>, api_key: web::Header<String>) -> impl Responder {
    // Vulnerable: only checks key validity, not org membership
    let valid = validate_api_key(&api_key).unwrap_or(false);
    if !valid {
        return HttpResponse::Unauthorized().finish();
    }
    // Direct use of user-supplied org_id and member_id
    let member = query_member_from_db(¶ms.org_id, ¶ms.member_id).await;
    HttpResponse::Ok().json(member)
}

fn validate_api_key(key: &str) -> bool {
    // simplistic check; in real systems validate format, revocation, etc.
    key.starts_with("ak_")
}
async fn query_member_from_db(org_id: &str, member_id: &str) -> Option<Member> {
    // Simulated DB call that does NOT check org membership for the key
    Some(Member { org_id: org_id.to_string(), member_id: member_id.to_string() })
}

Corrected pattern with per-request authorization

use actix_web::{web, HttpResponse, Responder};
use serde::{Deserialize, Serialize};

#[derive(Deserialize)]
struct Params {
    org_id: String,
    member_id: String,
}

struct ApiKeyRecord {
    key: String,
    allowed_orgs: Vec<String>,
}

async fn get_member_info(
    params: web::Query<Params>,
    api_key: web::Header<String>,
    key_store: web::Data<KeyStore>,
) -> impl Responder {
    let valid_record = key_store
        .records
        .iter()
        .find(|r| r.key == *api_key);

    match valid_record {
        Some(record) => {
            // Enforce that the requested org_id is in the key’s allowed list
            if !record.allowed_orgs.contains(¶ms.org_id) {
                return HttpResponse::Forbidden().body("Insufficient scope for this organization");
            }
            // Proceed with org-specific query that includes org_id as a filter
            let member = query_member_for_org(¶ms.org_id, ¶ms.member_id).await;
            match member {
                Some(m) => HttpResponse::Ok().json(m),
                None => HttpResponse::NotFound().body("Member not found"),
            }
        }
        None => HttpResponse::Unauthorized().body("Invalid API key"),
    }
}

async fn query_member_for_org(org_id: &str, member_id: &str) -> Option<Member> {
    // Simulated DB call that includes org_id in the filter
    // SELECT * FROM members WHERE org_id = $1 AND member_id = $2
    Some(Member { org_id: org_id.to_string(), member_id: member_id.to_string() })
}

struct KeyStore {
    records: Vec<ApiKeyRecord>,
}

#[derive(Serialize, Deserialize)]
struct Member {
    org_id: String,
    member_id: String,
}

Key improvements in the corrected pattern:

• The API key maps to a record that explicitly lists allowed organizations (allowed_orgs).
• The handler checks scope before using org_id, ensuring the key cannot be used to traverse unrelated resources.
• The database query includes the organization identifier as a mandatory filter, preventing accidental cross-tenant reads even if an identifier is guessed.

These steps align with remediation guidance provided by middleBrick’s findings, which highlight the importance of scoping checks and per-request authorization to mitigate BOLA/IDOR. The scanner validates whether changing identifiers while preserving the same key leads to unauthorized access, encouraging developers to implement strict ownership and tenant checks.