Bola Idor in Axum with Cockroachdb

Broken Object Level Authorization (BOLA) occurs when an API exposes internal object identifiers (such as database primary keys) and fails to enforce that the authenticated subject is authorized to access a specific instance. In an Axum application using CockroachDB, this typically arises when route parameters like user_id or document_id are directly used to construct CockroachDB SQL queries without verifying that the requesting user owns or is permitted to operate on that object.

Consider an endpoint GET /users/{user_id}/profile in Axum. If the handler extracts user_id from the path, passes it to a CockroachDB query like SELECT * FROM profiles WHERE id = $1, and returns the row without confirming that the authenticated actor matches user_id, the endpoint is vulnerable. An attacker who can guess or enumerate IDs can read or manipulate other users’ profiles. Because CockroachDB is a distributed SQL database that preserves SQL semantics, common patterns such as row-level security (RLS) can be used, but Axum does not enforce them automatically; developers must implement checks or use tenant-aware queries.

When OpenAPI/Swagger specs are analyzed (including $ref resolution), missing or inconsistent authorization scopes can highlight where BOLA risk exists across paths. middleBrick’s 12 security checks run in parallel and include BOLA/IDOR testing; it evaluates whether endpoints correctly scope data access and whether unauthenticated LLM endpoints might leak instructions that facilitate IDOR via prompt-injected payloads. The scanner cross-references spec definitions with runtime behavior, flagging endpoints where object-level authorization is absent.

Specific attack patterns relevant to this stack include:

• Insecure Direct Object Reference (IDOR) via predictable numeric IDs in URLs.
• Lack of row-level security or application-level tenant checks in CockroachDB queries.
• Overprivileged service accounts used by Axum services connecting to CockroachDB, enabling horizontal or vertical privilege escalation (BFLA).

Remediation guidance centers on ensuring that every data access includes the subject’s authorization context, using parameterized queries, and avoiding direct exposure of internal IDs where possible. The following section details concrete code fixes for CockroachDB in Axum.

To mitigate BOLA in Axum with CockroachDB, enforce authorization at the query layer and validate ownership before returning data. Below are concrete, realistic code examples using the sqlx crate with CockroachDB.

1. Use parameterized queries with explicit tenant/owner checks

// In your Axum handler
use axum::{routing::get, Router, extract::State};
use sqlx::PgPool;
use serde::Serialize;

#[derive(Serialize)]
struct ProfileResponse {
    id: i64,
    display_name: String,
}

async fn get_user_profile(
    State(pool): State<PgPool>,
    axum::extract::Path(user_id): axum::extract::Path<i64>,
    axum::extract::Auth(auth_id): Auth<i64>, // hypothetical extractor that provides authenticated user id
) -> Result<impl IntoResponse, (StatusCode, String)> {
    // Ensure the authenticated subject matches the requested resource
    let row: (String,) = sqlx::query_as("SELECT display_name FROM profiles WHERE id = $1 AND owner_id = $2")
        .bind(user_id)
        .bind(auth_id)
        .fetch_one(&pool)
        .await
        .map_err(|e| (StatusCode::NOT_FOUND, e.to_string()))?;

    Ok(Json(ProfileResponse { id: user_id, display_name: row.0 }))
}

The query filters by both id and owner_id, ensuring that even if an attacker guesses a valid profile ID, they cannot access it unless they are the owner.

2. Apply row-level security (RLS) in CockroachDB and rely on session context

Define a RLS policy on the table and set the application name or role per request so policies are enforced. In CockroachDB, you can use session variables or the crdb_internal session overrides.

-- CockroachDB setup
ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;

CREATE POLICY profiles_owner_policy ON profiles
  USING (auth_id() = owner_id);

-- Example function to set auth context per connection (called from Axum middleware)
SELECT set_config('app.current_user_id', '12345', false);

In Axum, establish a middleware that sets the session config before routing, so each CockroachDB query respects the policy. This keeps authorization close to the data and reduces the chance of missing checks in application code.

3. Avoid exposing internal IDs; use opaque identifiers

Replace database primary keys in URLs with UUIDs or hashes that do not reveal ownership information. Combine with authorization checks as shown above.

use uuid::Uuid;

async fn get_resource(
    State(pool): State<PgPool>,
    axum::extract::Path(public_id): axum::extract::Path<Uuid>,
    auth_id: Auth<i64>,
) -> Result<..., _> {
    let row: (i64,) = sqlx::query_as(
        "SELECT id FROM resources WHERE public_id = $1 AND owner_id = $2"
    )
    .bind(public_id)
    .bind(auth_id)
    .fetch_one(&pool)
    .await?;
    // proceed safely
}

By combining opaque identifiers, parameterized queries, and CockroachDB-side policies, you reduce the attack surface for BOLA/IDOR in Axum services.

middleBrick’s scans can validate these patterns by checking whether endpoints include proper scoping and whether spec definitions align with runtime behavior. Its CLI can be integrated into development workflows to surface findings early.