Broken Access Control in Actix with Bearer Tokens

Broken Access Control in Actix using Bearer Tokens typically arises when authorization checks are missing or inconsistently applied after token validation. In an Actix-web service that relies on bearer token authentication, developers may correctly validate the token’s signature and claims but fail to enforce role- or scope-based authorization for specific routes. This gap maps directly to the BOLA/IDOR and BFLA/Privilege Escalation checks performed by middleBrick, which test whether authenticated users can access or modify resources that should be restricted.

Consider an Actix endpoint that retrieves user profile data. If the route only verifies that a valid Bearer token exists, but does not ensure that the subject (sub) in the token matches the requested user identifier, an authenticated user can iterate over user IDs and access other profiles. middleBrick’s BOLA/IDOR testing includes verifying that object-level permissions are tied to the authenticated subject, not merely to a valid token. Similarly, privilege escalation can occur when a token with only read scope is used to invoke admin-only endpoints; this is captured by the BFLA/Privilege Escalation check, which examines whether authorization is re-evaluated at the handler level and not assumed after initial authentication.

Another common pattern in Actix is using middleware to attach a user role claim to request extensions, but then failing to inspect those claims in individual handlers. For example, an API may allow any authenticated user to delete records if a role claim is present in the request extensions, but the handler does not validate that the role has the necessary permissions for the specific resource. This can lead to horizontal privilege escalation across tenant boundaries or vertical escalation across admin functions. middleBrick’s Property Authorization check looks for such missing per-operation authorization by correlating spec-defined security schemes with runtime behavior, ensuring that endpoints requiring admin scope are not reachable by users with only user-level tokens.

Real-world attack patterns include IDOR via predictable numeric IDs, where a Bearer token provides access but does not enforce tenant or ownership scoping. For instance, an endpoint like GET /api/v1/accounts/{id} may return data for any numeric ID if the handler does not compare the token’s subject or tenant ID with the requested ID. Additionally, unauthenticated LLM endpoints that expose admin functionality compound the risk, as LLM/AI Security probes from middleBrick can identify token-less routes that should require strict authorization. These findings are mapped to frameworks such as OWASP API Top 10:2023 A01:2023 (Broken Access Control) and GDPR principles around data minimization and access control.

To summarize, the combination of Actix and Bearer Tokens exposes risk when token validation is treated as sufficient for authorization. middleBrick detects these issues by correlating OpenAPI/Swagger security schemes with runtime requests, testing whether valid tokens still lead to unauthorized data access or operations, and providing prioritized findings with remediation guidance.

Remediation centers on ensuring that after Bearer token validation, each handler enforces explicit authorization based on token claims and resource ownership. Below are concrete Actix-web examples that demonstrate secure patterns.

1. Validate token and enforce ownership

Ensure that the authenticated subject in the token matches the resource being accessed. Use extractor guards to short-circuit unauthorized requests.

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

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

async fn get_account(req: HttpRequest, path: web::Path) -> 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 or invalid authorization header"))?;

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

    let account_id = path.into_inner();
    // BOLA protection: ensure the subject in token matches the requested account ID
    if decoded.claims.sub != account_id.to_string() {
        return Ok(HttpResponse::Forbidden().finish());
    }

    // Proceed to fetch account for subject
    Ok(HttpResponse::Ok().json("Account data"))
}

2. Scope-based authorization for admin operations

Check scopes or roles from token claims at the handler level, not just in middleware. This prevents privilege escalation across admin and user endpoints.

use actix_web::{web, HttpRequest, HttpResponse, Result};

async fn admin_delete(req: HttpRequest, _payload: web::Json) -> Result {
    let token_claims = req.extensions().get::()
        .ok_or_else(|| actix_web::error::ErrorUnauthorized("Claims not found"))?;

    // BFLA protection: explicitly verify scope/role for admin action
    if token_claims.scope != "admin" {
        return Ok(HttpResponse::Forbidden().finish());
    }

    // Perform admin deletion
    Ok(HttpResponse::NoContent().finish())
}

3. Tenant-aware routing with extractor

For multi-tenant APIs, bind tenant ID from the token and enforce it in route parameters to prevent cross-tenant data access.

use actix_web::{web, HttpRequest, HttpResponse, Result};

async fn get_tenant_resource(
    req: HttpRequest,
    path: web::Path<(String, u32)>,
) -> Result {
    let token_claims = req.extensions().get::()
        .ok_or_else(|| actix_web::error::ErrorUnauthorized("Claims not found"))?;

    let (tenant_id, resource_id) = path.into_inner();
    // Property Authorization: ensure tenant_id from token matches path tenant
    if token_claims.tenant != tenant_id {
        return Ok(HttpResponse::Forbidden().finish());
    }

    // Proceed to fetch resource within tenant context
    Ok(HttpResponse::Ok().json("Tenant resource"))
}

4. Use middleware to attach claims, but validate in handlers

Middleware can populate request extensions, but handlers must still perform granular checks. This pattern keeps middleware lightweight and pushes authorization logic to the point of action.

use actix_web::{dev::ServiceRequest, Error, middleware::Next};
use actix_web::body::BoxBody;
use actix_web::http::HeaderValue;

async fn auth_middleware(
    req: ServiceRequest,
    next: Next,
) -> Result, Error> {
    if let Some(auth) = req.headers().get("authorization") {
        if let Ok(token) = auth.to_str().and_then(|s| s.strip_prefix("Bearer ")) {
            if let Ok(claims) = decode_token(token) {
                req.extensions_mut().insert(claims);
                return next.call(req).await;
            }
        }
    }
    Err(actix_web::error::ErrorUnauthorized("Unauthorized").into())
}

These examples enforce subject ownership, scope validation, and tenant scoping, directly addressing BOLA/IDOR and BFLA risks identified by middleBrick. By combining token validation with per-handler authorization, you reduce the attack surface exposed through Bearer token flows in Actix.