Idor Enumeration in Axum

Insecure Direct Object Reference (IDOR), classified as Broken Object Level Authorization (BOLA) in the OWASP API Top 10, occurs when an API exposes internal object identifiers (like database IDs) without verifying that the authenticated user has permission to access them. In Axum, this vulnerability commonly emerges from two patterns: using path parameters to fetch resources without ownership checks, and relying on predictable identifier schemes.

Axum's ergonomic extractors, such as Path<T>, can inadvertently encourage developers to write handlers that directly use extracted IDs to query databases. For example, a vulnerable user profile endpoint might look like this:

use axum::{extract::Path, routing::get, Router};

async fn get_user(Path(user_id): Path<u64>) -> String {
    // Directly query database with user_id without verifying current user's ownership
    format!("User data for ID: {}", user_id)
}

If the underlying database uses auto-incrementing integers or sequential UUIDs (v1/v2), an attacker can systematically enumerate valid IDs by incrementing values or guessing patterns. A request like GET /users/1 followed by GET /users/2 may reveal data for multiple users if no authorization check exists. Even with UUIDs, if they are generated from timestamps or MAC addresses (v1), enumeration remains feasible through brute-force or prediction.

Axum applications often combine this with JSON:API or RESTful conventions, where resource URLs like /api/orders/{order_id} become trivially enumerable. The absence of a middleware or guard that cross-references the extracted ID against the authenticated user's scope creates a direct pathway for horizontal privilege escalation. This is particularly dangerous in multi-tenant systems where a user from one tenant could access another's data simply by guessing an ID.

Detecting IDOR enumeration in Axum APIs requires a black-box approach that actively probes endpoints with varying identifiers and observes differential responses. middleBrick's BOLA/IDOR check automates this by analyzing your API's runtime behavior without credentials. It first parses your OpenAPI specification (if available) to understand parameter structures, then sends sequential requests with mutated path parameters, query parameters, and request bodies to identify unauthorized data access.

For an Axum API, middleBrick will test endpoints like /users/{id} by:

• Fetching a valid resource with a known ID (if any unauthenticated data exists).
• Submitting adjacent IDs (e.g., incrementing/decrementing integers, sequential UUID fragments).
• Comparing HTTP status codes, response bodies, and error messages across requests.
• Flagging inconsistencies—such as a 200 OK for /users/1 and /users/2—as potential enumeration vulnerabilities.

You can scan your Axum API instantly using the CLI tool:

middlebrick scan https://your-axum-api.com

The resulting report includes a letter grade (A–F), a per-category breakdown, and prioritized findings. For IDOR issues, you'll see details like:

• Endpoint: GET /users/{id}
• Evidence: Sequential integer IDs accepted; response contains user PII for multiple IDs.
• Severity: High (potential data breach).
• Remediation Guidance: Implement ownership checks; use non-guessable identifiers.

middleBrick's scoring maps this finding to OWASP API Top 10: BOLA, PCI-DSS requirement 6.5.8, and GDPR data protection principles. Unlike source-code scanners, it validates the actual runtime behavior of your deployed Axum service, catching misconfigurations even if the code looks correct.

Fixing IDOR enumeration in Axum requires enforcing strict authorization checks at the handler level and eliminating predictable identifiers. Axum's middleware and extractor system provides clean patterns to implement these controls.

1. Inject and Verify Current User Context
Use Axum's Extension to propagate the authenticated user from a prior middleware (e.g., JWT validation). Then, in each handler that accesses a resource by ID, compare the extracted ID against the current user's ID or owned resource list.

use axum::{extract::{Path, Extension}, http::StatusCode, Router};
use uuid::Uuid;

struct CurrentUser { id: Uuid, tenant_id: Uuid }

async fn get_user(
    Path(user_id): Path<Uuid>,
    Extension(current_user): Extension<CurrentUser>,
) -> Result<String, (StatusCode, &'static str)> {
    // Verify ownership: user can only access their own record
    if current_user.id != user_id {
        return Err((StatusCode::FORBIDDEN, "Access denied"));
    }
    // Safe to query database for this user_id
    Ok(format!("User data for ID: {}", user_id))
}

For multi-tenant systems, also validate tenant_id. This pattern centralizes authorization logic and prevents enumeration by rejecting mismatched IDs with a consistent 403 Forbidden.

2. Use Opaque, Non-Sequential Identifiers
Replace auto-incrementing integers or timestamp-based UUIDs (v1) with random UUIDv4 for database primary keys and API parameters. In your Axum resource creation handlers:

use uuid::Uuid;

async fn create_user(/* ... */) -> User {
    let user_id = Uuid::new_v4(); // Random, unguessable
    // Insert user with this user_id
}

This increases the keyspace exponentially (2¹²² possibilities), making enumeration computationally infeasible.

3. Implement Guard Layers
For repeated patterns, create a reusable guard function or middleware. Axum's from_request trait lets you build extractors that perform authorization before the handler runs:

use axum::{
    extract::FromRequestParts,
    http::{request::Parts, StatusCode},
};

struct RequireOwnership;

impl<S> FromRequestParts<S> for RequireOwnership {
    type Rejection = (StatusCode, &'static str);

    async fn from_request_parts(
        parts: &mut Parts,
        state: &S,
    ) -> Result<Self, Self::Rejection> {
        let Path(user_id) = Path::<Uuid>::from_request_parts(parts, state).await?;
        let Extension(current_user) = Extension::<CurrentUser>::from_request_parts(parts, state).await?;
        if current_user.id != user_id {
            return Err((StatusCode::FORBIDDEN, "Access denied"));
        }
        Ok(RequireOwnership)
    }
}

// Usage in handler:
async fn get_user(RequireOwnership, Path(user_id): Path<Uuid>) -> String { /* ... */ }

After applying these fixes, rescan with middleBrick to verify the BOLA/IDOR check passes. The Pro plan's continuous monitoring can alert you if new endpoints inadvertently reintroduce enumeration risks during development.

async fn get_user(Path(id): Path<u64>) -> User {
    db.find_user_by_id(id).await
}

async fn get_user(
    Path(id): Path<Uuid>,
    Extension(user): Extension<CurrentUser>,
) -> Result<User, (StatusCode, &'static str)> {
    if user.id != id { return Err(...) }
    db.find_user_by_id(id).await
}