Bola Idor in Actix with Bearer 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 Bearer Tokens for authentication, this risk emerges when token validation confirms identity but does not enforce ownership or role checks at the resource level.

Consider a typical Actix service that authenticates requests via a Bearer Token, extracts a user ID from the token payload, and then uses that ID to construct a database query. If the endpoint for retrieving or modifying a resource (e.g., /users/{user_id}/profile) only validates the presence and validity of the Bearer Token, but does not ensure that the user_id in the URL matches the user ID derived from the token, an attacker can modify the URL to access or manipulate other users’ profiles. Because the authentication layer accepts the Bearer Token, the request proceeds, and the application incorrectly assumes the authenticated user is authorized for the target resource.

In practice, this often maps to common API security weaknesses such as those cataloged in the OWASP API Security Top 10 and can be observed in endpoints that expose numeric or UUID identifiers without scoping them to the authenticated subject. For example, an endpoint like GET /api/v1/accounts/{account_id} that only checks for a valid Bearer Token allows horizontal privilege escalation if the token’s subject does not align with the requested account_id. Attackers can enumerate valid IDs or use leaked references to traverse across other users’ data, leading to unauthorized reads or updates.

Actix applications that rely on Bearer Tokens without additional object-level constraints amplify this risk when authorization logic is inconsistent or omitted across similar routes. Developers might correctly validate the token at the handler or via an extractor but forget to propagate the token’s subject into authorization checks for each business operation. This inconsistency means that some routes enforce ownership while others do not, creating a patchwork of protections that attackers can navigate by targeting the weakly protected endpoints.

Real-world scenarios include APIs where user IDs are exposed directly in paths, where foreign keys or tenant identifiers are missing from queries, or where an endpoint accepts an object reference that should be scoped to the authenticated user’s context. Because Bearer Tokens are widely used and easily integrated, the onus is on the application to couple authentication with robust, per-request authorization that ties each operation back to the token’s subject and enforces least-privilege access.

To mitigate BOLA in Actix when using Bearer Tokens, ensure that every handler validates not only the token’s authenticity but also that the requested resource belongs to the token’s subject. This requires extracting the subject from the token, using it to scope database or service queries, and avoiding direct use of user-controlled identifiers without ownership checks.

Below are concrete Actix code examples that demonstrate secure patterns. The first example shows a vulnerable approach where only authentication is enforced, and the second shows a corrected version with proper object-level authorization.

// Vulnerable: only checks Bearer Token, no ownership validation
use actix_web::{web, HttpResponse, HttpRequest};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};

async fn get_profile_user(req: HttpRequest, path: web::Path<(i32,)>) -> HttpResponse {
    let token = req.headers().get("Authorization")
        .and_then(|v| v.to_str().ok())
        .and_then(|s| s.strip_prefix("Bearer "));
    if let Some(token) = token {
        let _claims = decode::(
            token,
            &DecodingKey::from_secret(SECRET.as_ref()),
            &Validation::new(Algorithm::HS256),
        ).map_err(|_| HttpResponse::Unauthorized().finish())?;
        let user_id = path.0; // <-- attacker-controlled ID used directly
        let profile = db_get_profile_by_id(user_id);
        return HttpResponse::Ok().json(profile);
    }
    HttpResponse::Unauthorized().finish()
}

// Secure: token subject enforced at the object level
async fn get_profile_user_secure(
    req: HttpRequest,
    path: web::Path<(i32,)>
) -> HttpResponse {
    let token = req.headers().get("Authorization")
        .and_then(|v| v.to_str().ok())
        .and_then(|s| s.strip_prefix("Bearer "));
    let subject = match token {
        Some(token) => {
            let claims = decode::(
                token,
                &DecodingKey::from_secret(SECRET.as_ref()),
                &Validation::new(Algorithm::HS256),
            ).map_err(|_| HttpResponse::Unauthorized().finish())?;
            claims.sub // subject from token
        }
        None => return HttpResponse::Unauthorized().finish(),
    };
    let requested_id = path.0;
    if subject != requested_id {
        return HttpResponse::Forbidden().json(json!({ "error": "access denied" }));
    }
    let profile = db_get_profile_by_id(requested_id);
    HttpResponse::Ok().json(profile)
}

In the secure example, the subject extracted from the Bearer Token is compared to the requested identifier before any data access. This ensures that even if an attacker modifies the path parameter, the application will reject requests where the subject does not match. For UUID-based references, the same principle applies: compare the token subject with the resource’s owner ID or tenant ID before proceeding.

When designing Actix routes, prefer using extractor patterns that bind the subject early and propagate it into service functions. Avoid relying on route parameters alone for authorization decisions. Combine this approach with consistent error handling so that authorization failures return a 403 response rather than leaking information about resource existence.

For applications with multiple scopes or roles, encode permissions within the token and validate claims alongside object ownership. This layered defense reduces the likelihood of BOLA because both identity and entitlements are checked before data operations. Tools like middleBrick can support this posture by scanning your OpenAPI specs and runtime behavior to detect missing object-level constraints, especially in APIs using Bearer Tokens.