Bola Idor in Actix with Jwt Tokens

Broken Object Level Authorization (BOLA) occurs when an API lacks sufficient authorization checks between a user and a specific object, allowing one user to act on another user’s resources. In Actix web applications that use JWT tokens for authentication, BOLA emerges when endpoints validate the presence and structure of a JWT but omit per-request ownership or scope checks. A typical pattern is to decode the JWT to extract a user identifier (often a numeric ID or UUID) and then use that identifier only for logging or minimal claims checks, while directly exposing resource identifiers in URLs (e.g., GET /users/{user_id}/profile or PATCH /accounts/{account_id}). If the server does not confirm that the authenticated user represented by the JWT actually owns or is permitted to operate on the {user_id} or {account_id} in the path, an attacker can simply modify the numeric or UUID path segment to reference another valid object and gain unauthorized access.

JWT tokens in this context commonly carry a subject (sub) claim and possibly roles or scopes, but if the server relies solely on the token’s validity and does not cross-check the token’s claims against the targeted resource, the authorization boundary is effectively missing. For example, an endpoint that trusts the decoded JWT’s sub claim to identify the user but then performs a database lookup by a path-supplied user_id without verifying that sub equals user_id creates a straightforward BOLA. This is especially risky when IDs are predictable (integers or short UUIDs) and there are no additional runtime guards. Attack techniques include enumerating valid IDs, swapping tokens between sessions, or leveraging an intercepted token to probe endpoints with altered path parameters. In Actix, if route parameters are bound directly to handler arguments and the handler does not compare the authenticated identity from the JWT with the requested resource identifier, the application will expose BOLA. Common real-world patterns include inconsistent use of middleware that enforces ownership checks, missing row-level security in the data layer, and over-permissive role claims that are not validated at the resource level.

To illustrate with concrete Actix code, consider an endpoint that decodes a JWT and retrieves a user profile using a path parameter without verifying ownership:

use actix_web::{get, web, HttpResponse, Responder};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};

async fn get_profile(
    token: web::Query<AuthToken>,
    path: web::Path<(i32,)>, // (user_id from URL)
) -> impl Responder {
    let decoded = decode::<Claims>(
        &token.token,
        &DecodingKey::from_secret("secret".as_ref()),
        &Validation::new(Algorithm::HS256),
    );
    match decoded {
        Ok(token_data) => {
            let user_id_from_token = token_data.claims.sub; // i64 or i32
            let user_id_from_path = path.0;
            // BOLA: No check that user_id_from_token == user_id_from_path
            HttpResponse::Ok().json(fetch_user_profile(user_id_from_path))
        }
        Err(_) => HttpResponse::Unauthorized().finish(),
    }
}

In this example, the JWT is validated and a subject is extracted, but the handler trusts the path-supplied user_id implicitly. An authenticated user can change the URL’s user_id to access another profile. The vulnerability is not in JWT handling per se, but in the missing authorization check that the authenticated subject owns the requested resource. Similar issues arise with account identifiers, tenant IDs, or any object references embedded in URLs when the server does not enforce ownership derived from the JWT claims.

Remediation centers on ensuring that every data access decision ties the authenticated identity from the JWT directly to the requested resource. Instead of treating the path parameter as an opaque identifier, compare it with the subject or other authoritative claim from the token before querying the database. This can be implemented in Actix either within each handler or, preferably, in a dedicated extractor or middleware that enforces ownership globally.

First, define a strong Claims structure and a verified extractor that binds the authenticated identity to subsequent path parameters. The following example shows a custom extractor that validates the JWT and returns the authenticated user ID, which can then be compared with path-bound identifiers:

use actix_web::{dev::Payload, FromRequest, HttpMessage, HttpRequest};
use actix_web::error::ErrorUnauthorized;
use futures::future::{ok, Ready};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation, TokenData};

struct Auth {
    pub sub: i32,
}

impl FromRequest for Auth {
    type Error = actix_web::Error;
    type Future = Ready<Result<Self, Self::Error>>;

    fn from_request(req: &HttpRequest, _: &mut Payload) -> Self::Future {
        let token = match req.headers().get("Authorization") {
            Some(h) => h.to_str().unwrap_or("").trim_start_matches("Bearer "),
            None => return ok(Err(ErrorUnauthorized("Missing Authorization header"))),
        };
        let decoded: TokenData<Claims> = decode(
            token,
            &DecodingKey::from_secret("secret".as_ref()),
            &Validation::new(Algorithm::HS256),
        ).map_err(|_| ErrorUnauthorized("Invalid token"))?;
        ok(Ok(Auth { sub: decoded.claims.sub as i32 }))
    }
}

// Claims must derive Deserialize
use serde::Deserialize;
#[derive(Debug, Deserialize)]
struct Claims {
    sub: usize,
    // other claims
}

With this extractor, handlers can require both the authenticated identity and the path-bound identifier, then enforce that they match:

use actix_web::{web, HttpResponse, Responder};

async fn get_profile_secure(
    auth: Auth,           // authenticated identity from JWT
    path: web::Path<(i32,)>, // (user_id from URL)
) -> impl Responder {
    let user_id_from_path = path.0;
    // BOLA fix: compare authenticated subject with path parameter
    if auth.sub != user_id_from_path {
        return HttpResponse::Forbidden().json(serde_json::json!({
            "error": "access_denied",
            "message": "You can only access your own profile"
        }));
    }
    HttpResponse::Ok().json(fetch_user_profile(user_id_from_path))
}

For broader protection, implement a guard that validates ownership for any resource type. For example, a generic function can check that the authenticated subject matches a provided resource owner ID before allowing the operation. In Actix, you can wrap this logic in a service-level handler or use data extractors to enforce policies consistently. Also ensure that JWT validation uses strong algorithms (e.g., HS256/RS256), short expirations, and that keys are not exposed; rotate secrets regularly. Avoid trusting path or query parameters without cross-referencing the authenticated identity derived from the JWT.