Insecure Direct Object Reference in Axum with Mongodb

Insecure Direct Object Reference (IDOR) occurs when an API exposes internal object references—such as database IDs—and allows an authenticated user to access or modify data they should not see. In an Axum application using MongoDB, this typically arises when route parameters like user_id or document_id are taken directly from the request and used to construct a MongoDB query without verifying that the requesting user is authorized for that specific object.

Consider an endpoint like GET /users/{user_id}. If the handler uses the path parameter user_id to query MongoDB with a filter such as { _id: user_id } but does not also enforce that the authenticated subject owns or is permitted to view that document, the endpoint is vulnerable. For example, changing user_id from "65a1b2c3d4e5f6a7b8c9d0e1" to another valid ObjectId may return a different user record if the query does not include the current user’s identifier in the filter. This is an IDOR pattern because access control is applied at the route or resource level rather than at the data level.

With MongoDB, IDs are often ObjectId values, and developers might mistakenly treat them as opaque, trusting that the client-supplied value is safe to use directly. In Axum, this can happen when route extractors pass IDs straight into a repository function that builds a MongoDB filter without incorporating tenant or ownership context. Even when using JSON-based IDs or string identifiers, the same risk applies if the identifier is user-controlled and not validated against an access policy.

Another common scenario involves list or search endpoints where filters are built dynamically from request parameters. If an endpoint accepts a profile_id query parameter and uses it in a MongoDB find without confirming the profile belongs to the requesting user, an attacker can enumerate valid profile IDs to access other users’ data. This aligns with the OWASP API Top 10 category A1:2023 — Broken Object Level Authorization, and can be discovered by scanners such as middleBrick, which tests unauthenticated and authenticated attack surfaces to identify missing authorization checks.

In Axum with MongoDB, the combination of flexible schema design and permissive query construction increases the likelihood of IDOR when authorization logic is incomplete or inconsistent. Because MongoDB does not enforce schema-level permissions in the same way relational databases might, it is the application’s responsibility to ensure every query includes appropriate ownership or role-based filters. MiddleBrick’s checks for BOLA/IDOR and Property Authorization are designed to detect these missing constraints by correlating spec definitions with runtime behavior, highlighting endpoints where object-level permissions are not enforced.

To remediate IDOR in Axum with MongoDB, always include the requesting user’s identity or tenant context in the database query filter. Do not rely on route-level checks alone; enforce ownership or access rules at the data access layer. Below are concrete, executable examples that demonstrate secure patterns.

1. Include user identifier in the filter

Ensure that every query that retrieves or modifies a document also validates that the document belongs to the current user. For example, if you store the user’s ID in a JWT claim, pass it to your handler and use it in the MongoDB filter.

// src/handlers/user.rs
use axum::extract::State;
use mongodb::{bson::{doc, oid::ObjectId}};
use serde::Deserialize;

#[derive(Deserialize)]
pub struct UserParams {
    pub user_id: String,
}

pub async fn get_user_handler(
    State(db): State,
    current_user_id: String, // from auth layer
    params: axum::extract::Path,
) -> Result {
    // Secure: filter includes both the requested ID and the current user ID
    let filter = doc! {
        "_id": ObjectId::parse_str(¶ms.user_id).map_err(|_| (axum::http::StatusCode::BAD_REQUEST, "Invalid user ID"))?,
        "account_id": ¤t_user_id,
    };
    let collection = db.collection("users");
    let user = collection.find_one(filter, None).await.map_err(|e| (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    match user {
        Some(doc) => Ok(doc.to_string()),
        None => Err((axum::http::StatusCode::NOT_FOUND, "User not found or access denied".into())),
    }
}

2. Use a repository function that enforces ownership

Encapsulate data access logic in a repository or service layer so that filters are consistently applied. This reduces the risk of accidentally omitting authorization checks.

// src/repository/user_repo.rs
use mongodb::{Database, bson::{doc, oid::ObjectId}};

pub struct UserRepository {
    db: Database,
    current_user_id: String,
}

impl UserRepository {
    pub fn new(db: Database, current_user_id: String) -> Self {
        Self { db, current_user_id }
    }

    pub async fn find_by_id(&self, id: &str) -> Result, mongodb::error::Error> {
        let object_id = ObjectId::parse_str(id)?;
        let filter = doc! {
            "_id": object_id,
            "account_id": &self.current_user_id,
        };
        self.db.collection("users").find_one(filter, None).await
    }
}

3. Apply tenant or organization context for multi-tenant apps

In multi-tenant setups, store a tenant ID in each document and include it in every query. Never trust the client to filter by tenant.

// src/handlers/profile.rs
use mongodb::bson::doc;

pub async fn list_profiles_handler(
    State(db): State,
    current_user_id: String,
    tenant_id: String, // derived from subdomain or JWT claim
) -> Result {
    let filter = doc! {
        "owner_id": ¤t_user_id,
        "tenant_id": &tenant_id,
    };
    let collection = db.collection("profiles");
    let cursor = collection.find(filter, None).await.map_err(|e| (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    let docs: Vec<_> = cursor.try_collect().await.map_err(|e| (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    Ok(serde_json::to_string(&docs).unwrap_or_default())
}

4. Validate and sanitize input before constructing queries

Always parse and validate IDs before using them in MongoDB filters to avoid injection or malformed queries. Use strong types for identifiers where possible.

// src/lib.rs
use mongodb::bson::oid::ObjectId;

pub fn parse_object_id(input: &str) -> Result {
    ObjectId::parse_str(input)
}

// In handler:
let parsed_id = parse_object_id(¶ms.user_id)?;
let filter = doc! { "_id": parsed_id, "account_id": current_user_id };

5. Avoid exposing sequential or guessable identifiers

Where feasible, use non-sequential, opaque identifiers (e.g., UUIDs or encoded ObjectIds) to make enumeration harder. Combine this with ownership checks for defense in depth.

use mongodb::bson::doc;

let filter = doc! {
    "public_id": ¶ms.public_id,
    "user_id": current_user_id,
};
let doc = db.collection("resources").find_one(filter, None).await?;