Insecure Direct Object Reference in Axum with Cockroachdb

Insecure Direct Object Reference (IDOR) occurs when an API exposes a reference to a resource—such as a numeric ID or UUID—and uses that reference directly to authorize access, without verifying that the requesting identity is permitted to interact with that specific resource. When you build an API in Axum that relies on a CockroachDB backend, the combination of predictable resource identifiers and missing ownership or tenant checks can expose data belonging to other users.

Consider a typical Axum handler that extracts a user_id from the URL and queries CockroachDB via a SQLx or diesel-like interface. If the handler constructs a query like SELECT * FROM profiles WHERE id = $1 using only the user_id from the request, it directly references a database row using an identifier controlled by the client. Without verifying that the authenticated actor is allowed to access that row, an attacker can increment or guess IDs and read or manipulate other users’ profiles. This becomes more impactful with CockroachDB because its distributed SQL semantics do not reduce the need for application-level authorization; the database enforces consistency and permissions but does not enforce business-level access rules.

Common patterns that lead to IDOR in Axum include:

• Using path or query parameters as direct database keys without scoping to the authenticated subject.
• Relying solely on role-based checks (e.g., "is admin?") when the operation must be scoped to a specific record owner or tenant.
• Exposing internal identifiers such as CockroachDB primary keys or sequence IDs in URLs, which are easy to enumerate.

Even when you use an OpenAPI spec and generate route parameters in Axum, the framework does not automatically enforce that the authenticated user matches the resource owner. The scan categories in middleBrick—such as BOLA/IDOR and Property Authorization—are designed to detect these missing ownership checks by correlating runtime behavior against the declared spec. In an Axum + Cockroachdb stack, the spec may describe a /users/{user_id} endpoint, but if the implementation does not bind the authenticated identity to the user_id in SQL predicates, the unauthenticated attack surface includes direct record access.

Additionally, CockroachDB’s secondary indexes and distributed tables do not inherently prevent IDOR; they simply mean that lookups by indexed keys remain fast. If your authorization logic is incomplete, an attacker can leverage predictable, sequential IDs or known UUIDs to traverse other users’ data. MiddleBrick’s unauthenticated scan would flag this as a BOLA/IDOR finding, noting that the endpoint exposes a direct object reference without adequate property-level authorization checks.

To remediate IDOR in Axum with CockroachDB, you must scope every data access to the authenticated subject and enforce tenant or ownership checks in SQL. Below are concrete patterns and code examples.

1. Scope queries to the authenticated identity

Instead of using the client-supplied identifier as the sole lookup key, derive the database key from the combination of the authenticated principal and the requested identifier. For example, if you store a user_id in the session or JWT claims, use it to filter rows:

// Axum handler example with SQLx and PostgreSQL (CockroachDB compatible)
use axum::extract::{Query, State, Extension};
use serde::Deserialize;
use sqlx::PgPool;
use uuid::Uuid;

#[derive(Deserialize)]
pub struct ProfileQuery {
    pub profile_id: Uuid,
}

pub async fn get_profile_handler(
    Extension(pool): Extension,
    Query(params): Query,
    // Assume get_current_user returns a user_id from JWT/session
    current_user: (Uuid,),
) -> Result {
    let (user_id,) = current_user;
    // Enforce ownership in SQL: combine authenticated user_id with requested profile_id
    let profile = sqlx::query!(
        "SELECT id, display_name, user_id FROM profiles WHERE id = $1 AND user_id = $2",
        params.profile_id,
        user_id
    )
    .fetch_optional(&pool)
    .await
    .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?
    .ok_or_else(|| (StatusCode::NOT_FOUND, "Profile not found".to_string()))?;

    Ok(Json(serde_json::json!({
        "id": profile.id,
        "display_name": profile.display_name,
    })))
}

This ensures that even if an attacker guesses or iterates profile IDs, they can only retrieve profiles where the row’s user_id matches the authenticated subject. The CockroachDB SQL engine will still use the index efficiently because the predicate includes both id and user_id.

2. Use tenant-aware tables or row-level security

If your application serves multiple tenants, consider a tenant_id column and scope queries accordingly. CockroachDB supports standard SQL constructs, so you can include tenant_id in the primary key or enforce it in WHERE clauses:

// Assuming a tenant_id column exists on profiles
let profile = sqlx::query!(
    "SELECT id, display_name, user_id, tenant_id FROM profiles WHERE id = $1 AND tenant_id = $2 AND user_id = $3",
    params.profile_id,
    current_tenant_id,
    user_id
)
.fetch_optional(&pool)
.await?
.ok_or(...)?;

3. Avoid exposing internal CockroachDB keys directly

Prefer opaque identifiers (e.g., UUIDs) over sequential integers, and do not rely on primary keys alone for authorization. Combine business keys with ownership checks.

middleBrick’s checks—such as Property Authorization and BOLA/IDOR—can validate that your endpoints enforce these scoping rules. By correlating the OpenAPI definition of /users/{user_id} with runtime behavior, it can highlight missing constraints and provide prioritized findings with remediation guidance.