Insecure Direct Object Reference in Actix with Jwt Tokens

Insecure Direct Object Reference (BOLA/IDOR) occurs when an API exposes internal object references—such as database IDs or usernames—in endpoints without verifying that the authenticated subject has permission to access the specific resource. In Actix, this commonly arises when route parameters like user_id or resource_id are taken directly from the request and used to query data, while authorization checks are incomplete or misaligned with the JWT-based identity.

When JWT tokens are used for authentication, the identity (e.g., user ID or roles) is typically encoded in the token payload. If Actix routes rely solely on the token for authentication but then use route-supplied identifiers without confirming that the identifier matches the subject represented by the JWT, an IDOR emerges. For example, consider an endpoint GET /users/{user_id} that reads user_id from the path. If the handler only validates the JWT to confirm a user is logged in, but does not ensure the user_id in the path matches the user ID in the JWT, one user can enumerate or access another user’s profile by altering the path parameter.

Actix-web applications often use extractor patterns such as web::Path and web::Query to bind route parameters. Without an explicit authorization step that compares the JWT subject to the parameter, the unauthenticated attack surface includes IDOR via path manipulation. Even when JWT validation is enforced via middleware or guards, if the authorization logic is incomplete—such as allowing access to list all users or fetch any user by ID—this creates a BOLA/IDOR vector. Common root causes include missing ownership checks, overly permissive role-based access that does not scope data, and assumptions that client-supplied identifiers are trustworthy after authentication.

In more complex scenarios, JWTs may carry roles or scopes, and developers might implement coarse-grained checks (e.g., requiring the admin scope) while neglecting object-level authorization. An attacker can still traverse other users’ resources if numeric IDs are predictable or guessed. Because Actix does not inherently enforce scoping between JWT claims and resource identifiers, the developer must explicitly align the subject from the JWT with the resource being accessed. This requires extracting the subject from the validated JWT, querying the data with that subject as a filter, and ensuring the query returns a result; a missing result should be treated as an authorization failure rather than a not-found.

Another subtle IDOR risk arises with query parameters or body fields that reference other objects. For instance, an endpoint that changes a user’s email might accept a JSON payload with a target_user_id. If the handler updates that user without verifying that the authenticated subject (from the JWT) is permitted to modify it, the endpoint becomes an IDOR channel. In Actix, this can occur when deserialization binds JSON to a struct and business logic proceeds without cross-checking JWT subject ownership. Because the attack surface is the unauthenticated enumeration of identifiers and the misuse of authenticated context, robust scoping is essential to prevent IDOR.

To detect this during scanning, middleBrick tests the unauthenticated attack surface by probing endpoints with different identifiers while authenticated as a generic subject, looking for differences in behavior or data exposure that indicate missing authorization. In environments using OpenAPI specs, it cross-references path and query parameters with security schemes to highlight endpoints where identifiers are accepted without explicit scoping to the authenticated subject. This helps surface BOLA/IDOR risks in Actix services that rely on JWT tokens without rigorous object-level checks.

Remediation focuses on ensuring that every access to a resource validates not only the JWT but also that the resource identifier aligns with the subject (or required permissions) expressed by the token. Below are concrete patterns for Actix-web in Rust that demonstrate secure handling.

Example 1: Scoped access to a user profile

Extract the subject from the validated JWT and use it to scope the database query. Do not trust user_id from the path alone.

use actix_web::{web, HttpResponse, Result};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use serde::{Deserialize, Serialize};

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

async fn get_user_profile(
    path: web::Path, // user_id from path
    token: actix_web::HttpRequest,
) -> Result {
    // Assume `token` has been validated and claims extracted earlier.
    // In practice, extract claims in an extractor or middleware.
    let token_str = token.headers().get("Authorization")
        .and_then(|v| v.to_str().ok())
        .and_then(|s| s.strip_prefix("Bearer "))
        .ok_or_else(|| actix_web::error::ErrorUnauthorized("Invalid auth"))?;

    let claims = decode::(
        token_str,
        &DecodingKey::from_secret("secret".as_ref()),
        &Validation::new(Algorithm::HS256),
    ).map_err(|_| actix_web::error::ErrorUnauthorized("Invalid token"))?;

    let requested_id = path.into_inner();
    // Enforce scoping: requested_id must match the subject from JWT
    if requested_id != claims.sub {
        return Ok(HttpResponse::Forbidden().finish());
    }

    // Proceed to fetch user data safely, e.g., via a repository that uses claims.sub
    // let user = user_repo.find_by_id(&claims.sub)?;
    Ok(HttpResponse::Ok().json(()))
}

Example 2: Admin operation with role scoping

When an endpoint requires elevated privileges, verify roles/scopes from the JWT and ensure the operation is limited to permitted actions. Do not allow arbitrary IDs without ownership checks.

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

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

async fn update_user_email(
    payload: web::Json,
    req: actix_web::HttpRequest,
) -> actix_web::Result {
    let token = req.headers().get("Authorization")
        .and_then(|v| v.to_str().ok())
        .and_then(|s| s.strip_prefix("Bearer "))
        .ok_or_else(|| actix_web::error::ErrorUnauthorized("Missing token"))?;

    let claims = decode::(
        token,
        &DecodingKey::from_secret("secret".as_ref()),
        &Validation::new(Algorithm::HS256),
    ).map_err(|_| actix_web::error::ErrorUnauthorized("Invalid token"))?;

    let target_user_id = &payload.user_id;
    // Ensure the requester is allowed to modify this user.
    // Admins may act on any user; otherwise, they must be the same subject.
    let is_admin = claims.roles.iter().any(|r| r == "admin");
    if !(is_admin || target_user_id == &claims.sub) {
        return Err(actix_web::error::ErrorForbidden("Not authorized"));
    }

    // Proceed with update, using target_user_id scoped by authorization checks
    // update_user_email_service(target_user_id, &payload.email).await?;
    Ok(HttpResponse::Ok().finish())
}

General guidelines for Actix + JWT

• Always extract the JWT subject (sub) and roles/scopes after validation and use them in data access queries.
• Do not rely only on path or query parameters for object references; enforce ownership or role-based scoping.
• Treat missing resources as authorization failures when the subject is verified, to avoid user enumeration via timing differences.
• Use middleware or request guards to centralize JWT validation and expose claims to handlers, reducing repetitive checks.
• When using OpenAPI specs, ensure security schemes reference JWTs and that path parameters involved in IDOR-prone endpoints are explicitly documented with scoping expectations.

By tying JWT subject claims to resource identifiers in Actix handlers and rejecting requests where the identifier does not match the authenticated subject’s permissions, you mitigate BOLA/IDOR while preserving the convenience of token-based authentication.