Identification Failures in Axum with Cockroachdb

Identification failures occur when an API incorrectly identifies or fails to identify a user or resource, allowing one actor to assume the identity of another. In an Axum application using Cockroachdb as the backend, this typically maps to the BOLA/IDOR checks within middleBrick’s scan. The database schema, query construction, and route parameter handling must consistently enforce identity boundaries; missing checks at any layer enable horizontal privilege escalation.

With Cockroachdb, a distributed SQL database, the risk often arises from how primary keys and indexes are composed. If a table uses a composite primary key such as (tenant_id, resource_id) but route handlers only validate resource_id, an attacker can iterate resource_id values across tenants. Cockroachdb’s SQL semantics do not inherently enforce tenant isolation at the query layer; it is the application’s responsibility to ensure every statement includes the tenant context. An Axum handler that builds SQL like SELECT * FROM resources WHERE id = $1 without joining or filtering on tenant_id enables an attacker to supply any ID and retrieve another tenant’s data, assuming predictable or guessed IDs.

Another vector specific to Axum middleware involves request guard extraction and state. Axum extracts extension data and typed extractors to build authorization context. If the tenant identifier is stored in an extension or claim and not re-validated against Cockroachdb per request, an attacker can tamper with the JWT or session payload to change tenant_id while keeping the same route parameters. Because Cockroachdb returns rows according to the WHERE clause, omitting tenant_id in WHERE clauses effectively bypasses identity checks despite correct route parameter parsing.

Serialization and ORM usage can also contribute. When using SQLx or a query builder, mismatched type handling between Rust integers and Cockroachdb’s UUID or INT primary keys may lead to incorrect row matches. For example, casting a string UUID to a column without proper parameterization may result in implicit type conversions that bypass intended identification, especially if the ORM or query builder inadvertently constructs a condition that does not include tenant context. middleBrick’s BOLA/IDOR checks highlight these patterns by correlating OpenAPI path parameters with runtime SQL conditions, surfacing endpoints where the identifier is not bound to the authenticated subject or tenant.

Real-world patterns to watch for include missing WHERE clauses on tenant columns, use of generic IDs without scoping, and inconsistent use of guards across middleware layers. Since Axum does not enforce data isolation by default, developers must explicitly embed tenant_id or user_id into every database predicate. middleBrick’s scan can detect these gaps by testing unauthenticated and authenticated contexts, probing ID substitution across tenant boundaries and analyzing the OpenAPI spec’s path definitions against the observed SQL behavior to prioritize findings with clear remediation guidance.

Remediation centers on ensuring that every database query includes tenant or user context derived from the authenticated subject, and that route parameters are validated against the correct identity scope. Below are concrete Axum patterns with Cockroachdb using SQLx, demonstrating how to enforce identification correctly.

First, define a typed extractor for the authenticated subject that includes tenant_id:

use axum::extract::Extension;
use serde::{Deserialize, Serialize};

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct AuthSubject {
    pub user_id: i64,
    pub tenant_id: i64,
}

pub async fn require_auth(req: Request<B>) -> Result<(Extension<AuthSubject>, Request<B>), Response> {
    // validate token, set AuthSubject
    let subject = validate_token(req).await?;
    Ok((Extension(subject), req))
}

use axum::routing::get;
use sqlx::PgPool;
use std::net::SocketAddr;
use axum::Router;

async fn get_resource(
    Extension(subject): Extension<AuthSubject>,
    Path(resource_id): Path<i64>,
    pool: Extension<PgPool>,
) -> Result<Json<Resource>, (StatusCode, String)> {
    let row = sqlx::query!(
        r#"SELECT id, name, tenant_id FROM resources WHERE id = $1 AND tenant_id = $2"#,
        resource_id,
        subject.tenant_id
    )
    .fetch_optional(pool.as_ref())
    .await
    .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?
    .ok_or((StatusCode::NOT_FOUND, "Resource not found".to_string()))?;

    Ok(Json(Resource {
        id: row.id,
        name: row.name,
    }))
}

#[tokio::main]
async fn main() {
    let pool = PgPool::connect("postgresql://user:pass@host/db").await.unwrap();
    let app = Router::new()
        .route("/resources/:id", get(get_resource))
        .layer(Extension(pool));
    // run omitted
}

sqlx::query!(
    r#"SELECT id, tenant_id FROM user_resources WHERE tenant_id = $1 AND resource_id = $2"#,
    subject.tenant_id,
    resource_id
)
.fetch_one(pool.as_ref())
.await?;

async fn tenant_guard(
    Extension(subject): Extension<AuthSubject>,
    Path(resource_id): Path<i64>,
    pool: Extension<PgPool>,
) -> Result<(), (StatusCode, String)> {
    let count: (i64,) = sqlx::query_as(
        r#"SELECT 1 FROM resources WHERE id = $1 AND tenant_id = $2 LIMIT 1"#,
    )
    .bind(resource_id)
    .bind(subject.tenant_id)
    .fetch_one(pool.as_ref())
    .await
    .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    if count.0 == 1 {
        Ok(())
    } else {
        Err((StatusCode::FORBIDDEN, "Access denied".into()))
    }
}