Bola Idor in Axum with Jwt Tokens

Broken Object Level Authorization (BOLA) occurs when an API fails to enforce authorization checks between a user and a specific object identifier (ID). In Axum, this commonly arises when endpoints use a JWT token to identify the authenticated user but then use a user-controlled parameter (e.g., a resource ID in the path or query) to fetch or act on another resource without verifying ownership or permissions.

Consider a route like /users/{user_id}/profile. If the handler decodes the JWT to obtain the subject (sub) and then directly uses user_id from the path without comparing it to the sub claim, an authenticated user can change user_id to access another user’s profile. The JWT provides identity, but without explicit object-level checks it does not prevent horizontal privilege escalation across objects belonging to different users.

In Axum, this often maps to the BOLA/IDOR category in middleBrick’s 12 security checks. The scanner tests unauthenticated and authenticated-like scenarios (where a valid JWT is supplied) to detect whether endpoints properly enforce that the requesting subject has the necessary relationship to the target object. A vulnerable implementation might validate the token, deserialize it into claims, and then perform an unchecked database lookup indexed by the path ID, effectively exposing a direct BOLA flaw.

Real-world analogs include endpoints that expose internal numeric IDs without scoping to the caller, or endpoints that accept a UUID for a document, order, or record without confirming the caller’s association to that UUID. Even with JWTs, if the server does not enforce that the token’s subject matches the resource identifier (or a required relationship), the API remains vulnerable to BOLA. This can lead to unauthorized reads, updates, or deletes of other users’ data, and is frequently listed among OWASP API Top 10 findings and relevant compliance mappings such as SOC2 and GDPR.

To remediate BOLA when using JWT tokens in Axum, ensure that every data access path validates the relationship between the authenticated subject and the requested object identifier. Below are concrete, idiomatic examples that demonstrate secure handling.

Example 1: Scoped profile retrieval

Assume a /users/{user_id}/profile endpoint where the JWT’s sub claim identifies the user. The handler should extract both the path parameter and the claim and ensure they match before proceeding.

use axum::extract::{Path, State, Json};
use axum::http::StatusCode;
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize)]
struct Claims {
    sub: String,
    // other claims...
}

#[derive(Debug, Serialize)]
struct Profile {
    user_id: String,
    display_name: String,
}

async fn get_profile(
    State(_state): State<AppState>,
    Path(path): Path<(String,)>,
    auth_header: Option<axum::http::HeaderValue>,
) -> Result<Json<Profile>, (StatusCode, String)> {
    let token = auth_header.ok_or((StatusCode::UNAUTHORIZED, "missing token".to_string()))?;
    let token = token.to_str().map_err(|_| (StatusCode::UNAUTHORIZED, "invalid token encoding"))?;
    let decoded = decode::

use axum::extract::{Path, State};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};

#[derive(Debug, Deserialize)]
struct Claims {
    sub: String,
    roles: Vec<String>,
}

async fn admin_update_user(
    State(_state): State<AppState>,
    Path(target_user_id): Path<String>,
    auth_header: axum::http::HeaderValue,
) -> Result<axum::http::StatusCode, (axum::http::StatusCode, String)> {
    let token = auth_header.to_str().map_err(|_| (StatusCode::UNAUTHORIZED, "invalid token"))?;
    let decoded = decode::