Broken Access Control in Axum with Jwt Tokens

Broken Access Control in Axum when using Jwt Tokens commonly arises because developers validate the token’s signature and expiry but do not enforce authorization checks on individual routes or resources. Axum is a flexible framework that requires explicit route guards; if those guards are omitted or applied inconsistently, an authenticated user can access endpoints intended for other users or roles. This becomes a BOLA/IDOR pattern when object-level permissions are missing or when identifiers are exposed in URLs without verification.

Consider an endpoint like /users/{user_id}/profile. If the handler only checks that a valid Jwt Token exists and does not confirm that the requesting user matches the user_id in the path, an attacker can increment the ID and view or modify other profiles. Jwt Tokens in this context often carry a sub claim representing the user identifier. If the application trusts the token’s payload but does not re-check ownership or role-based permissions on each request, the access control boundary is effectively bypassed.

Axum middleware can extract and decode Jwt Tokens, but developers must ensure that every sensitive route applies both authentication and authorization. For example, using a middleware that attaches a Claims struct to the request extension is useful, yet it does not replace explicit checks inside handlers or via dedicated authorization layers. Without such checks, the API surface remains vulnerable to horizontal privilege escalation (accessing peers’ data) and vertical privilege escalation (accessing admin endpoints) despite valid Jwt Tokens.

Real-world attack patterns mirror findings from OWASP API Top 10 and common bug bounty programs where missing object-level authorization in REST APIs leads to unauthorized data access. In Axum applications, this often maps to missing or incomplete checks on resource ownership or insufficient role validation before performing data operations.

Remediation focuses on ensuring that every request with Jwt Tokens is authenticated and that each operation is authorized for the specific resource and action. Use typed claims extraction, enforce ownership checks, and prefer role-based access control (RBAC) or attribute-based access control (ABAC) patterns consistently.

First, define a claims structure that matches your Jwt Token contents and implement an extractor that decodes and validates the token. Then, attach the claims to the request extensions so handlers can reference them safely without re-decoding.

use axum::{async_trait, extract::FromRequestParts, http::request::Parts};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
pub struct Claims {
    pub sub: String,
    pub role: String,
    pub exp: usize,
}

pub struct AuthUser {
    pub user_id: String,
    pub role: String,
}

#[async_trait]
impl FromRequestParts for AuthUser
where
    S: Send + Sync,
{
    type Rejection = (http::StatusCode, String);

    async fn from_request_parts(parts: &mut Parts, _state: &S) -> Result {
        let token = parts
            .headers
            .get("authorization")
            .and_then(|v| v.to_str().ok())
            .and_then(|s| s.strip_prefix("Bearer "))
            .ok_or((http::StatusCode::UNAUTHORIZED, "Missing or invalid auth header".to_string()))?;

        let key = DecodingKey::from_secret("your_secret".as_ref());
        let mut validation = Validation::new(Algorithm::HS256);
        validation.validate_exp = true;

        let token_data = decode::(token, &key, &validation)
            .map_err(|_| (http::StatusCode::UNAUTHORIZED, "Invalid token".to_string()))?;

        Ok(AuthUser {
            user_id: token_data.claims.sub,
            role: token_data.claims.role,
        })
    }
}

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

async fn get_user_profile(
    AuthUser { user_id, role }: AuthUser,
    Path(requested_id): Path,
) -> Result {
    if user_id != requested_id && role != "admin" {
        return Err((http::StatusCode::FORBIDDEN, "Unauthorized".to_string()));
    }
    // Proceed to fetch and return the profile for requested_id
    Ok(format!("Profile for {}", requested_id))
}

fn app() -> Router {
    Router::new().route("/users/:user_id/profile", get(get_user_profile))
}