Broken Access Control in Actix

Broken Access Control in Actix applications typically manifests through missing or improperly implemented authorization checks, particularly in route handlers that should restrict access based on user roles, ownership, or permissions. The most common patterns involve forgetting to validate whether the authenticated user has rights to perform actions on specific resources.

A classic Actix vulnerability occurs when developers rely solely on authentication middleware without implementing proper authorization checks. For example:

async fn update_profile(
    data: web::Data<AppState>, 
    id: web::Path<u32>, 
    form: web::Json<UpdateProfile>
) -> impl Responder {
    let db = &data.db;
    
    // Missing authorization check!
    // Any authenticated user can update any profile
    let result = db.update_profile(id, form.0).await;
    
    match result {
        Ok(_) => HttpResponse::Ok().finish(),
        Err(_) => HttpResponse::InternalServerError().finish()
    }
}

This handler allows any authenticated user to update any profile by simply changing the URL parameter. The proper implementation requires verifying that the authenticated user matches the profile being updated:

async fn update_profile(
    data: web::Data<AppState>, 
    id: web::Path<u32>, 
    form: web::Json<UpdateProfile>, 
    auth: AuthUser // From authentication middleware
) -> impl Responder {
    let db = &data.db;
    
    // Critical authorization check
    if auth.user_id != id.into_inner() {
        return HttpResponse::Forbidden().finish();
    }
    
    let result = db.update_profile(auth.user_id, form.0).await;
    
    match result {
        Ok(_) => HttpResponse::Ok().finish(),
        Err(_) => HttpResponse::InternalServerError().finish()
    }
}

Another common Actix pattern is BOLA (Broken Object Level Authorization) in database queries where user input directly maps to resource identifiers without ownership validation:

async fn get_user_data(
    web::Path((user_id)): web::Path<(u32,)>,
    data: web::Data<AppState>
) -> impl Responder {
    let db = &data.db;
    
    // Vulnerable: no check that requesting user owns this data
    let user_data = db.get_user_data(user_id).await;
    
    match user_data {
        Ok(data) => HttpResponse::Ok().json(data),
        Err(_) => HttpResponse::NotFound().finish()
    }
}

The Actix ecosystem's async/await patterns can exacerbate these issues when developers forget to propagate user context through service layers, leading to authorization checks being bypassed in business logic.

Detecting Broken Access Control in Actix applications requires both static analysis of route handlers and dynamic testing of authorization boundaries. middleBrick's API security scanner specifically tests Actix applications for these vulnerabilities through its black-box scanning approach.

The scanner identifies Actix-specific patterns by examining endpoint structures and testing for common authorization bypasses. For instance, it automatically attempts to access resource endpoints with different authenticated user contexts to detect missing ownership checks:

// Example of what middleBrick tests for:
// 1. Access resource A with User 1's token
// 2. Access same resource A with User 2's token
// 3. If both succeed, BOLA vulnerability detected

middleBrick's LLM/AI Security module also detects Actix applications that might be vulnerable to prompt injection if they use AI features for authorization decisions. The scanner tests for:

• Missing role-based access control (RBAC) in Actix route handlers
• Direct object reference vulnerabilities in path parameters
• Missing authorization middleware in protected routes
• Excessive agency patterns where AI agents might make unauthorized decisions

For Actix applications using middleware for authentication, middleBrick verifies that authorization checks are properly chained after authentication:

use actix_web::{guard, web, App, HttpServer, HttpResponse};

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            // Authentication middleware
            .wrap(middleware::Authentication)
            // Authorization middleware (critical!)
            .wrap(middleware::Authorization)
            .service(web::resource("/admin")
                .guard(guard::fn_guard(|req| {
                    // Check user role from request context
                    let user = req.app_data::();
                    user.map(|u| u.role == "admin").unwrap_or(false)
                }))
                .to(admin_handler))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

The scanner also checks for Actix-specific anti-patterns like using web::Data for user context instead of request-scoped data, which can lead to authorization context being lost across async boundaries.

Fixing Broken Access Control in Actix requires implementing proper authorization patterns using Actix's native middleware and request-scoped data features. The most effective approach is creating dedicated authorization middleware that validates permissions before route handlers execute.

use actix_web::{
    dev::ServiceRequest, dev::ServiceResponse, 
    http::header, Error, FromRequest
};

use jsonwebtoken::{decode, Validation};

use std::sync::Arc;

#[derive(Debug, serde::Deserialize)]
struct Claims {
    user_id: u32,
    role: String,
    exp: usize,
}

struct AuthenticatedUser {
    user_id: u32,
    role: String,
}

impl FromRequest for AuthenticatedUser {
    type Config = ();
    type Error = Error;
    type Future = futures::future::Ready<Result<Self, Self::Error>>;

    fn from_request(req: &ServiceRequest, _payload: &mut actix_http::Payload) 
        -> Self::Future {
        
        let auth_header = match req.headers().get(header::AUTHORIZATION) {
            Some(header) => header.to_str().unwrap_or(""),
            None => return futures::future::ready(Err(Error::from(()))),
        };

        if !auth_header.starts_with("Bearer ") {
            return futures::future::ready(Err(Error::from(())));
        }

        let token = auth_header.trim_start_matches("Bearer ");
        let validation = Validation::new(jsonwebtoken::Algorithm::HS256);
        
        match decode<Claims>(token, b"secret", &validation) {
            Ok(token) => {
                let user = AuthenticatedUser {
                    user_id: token.claims.user_id,
                    role: token.claims.role,
                };
                futures::future::ready(Ok(user))
            }
            Err(_) => futures::future::ready(Err(Error::from(()))),
        }
    }
}

struct AuthorizationMiddleware;

impl actix_web::middleware::NewMiddleware<S> for AuthorizationMiddleware 
where 
S: actix_web::dev::Service> +
    'static,
B: actix_http::body::MessageBody +
    'static,
{
    type Middleware = AuthorizationService<S>;
    type Config = ();
    type Error = Error;
    type Future = futures::future::Ready<Result<Self::Middleware, Self::Error>>;

    fn new_middleware(&self, service: S) -> Self::Future {
        futures::future::ready(Ok(AuthorizationService { service }))
    }
}

struct AuthorizationService<S> {
    service: S,
}

impl<S, B> actix_web::dev::Service for AuthorizationService<S>
where 
S: actix_web::dev::Service<Request = ServiceRequest, Response = ServiceResponse<B>> +
    'static,
B: actix_http::body::MessageBody +
    'static,
{
    type Request = ServiceRequest;
    type Response = ServiceResponse<B>;
    type Error = Error;
    type Future = futures::future::BoxFuture<'static, Result<Self::Response, Self::Error>>;

    actix_web::dev::forward_ready!(service);

    fn call(&mut self, mut req: ServiceRequest) -> Self::Future {
        // Extract authenticated user from request extension
        let user = match req.get_extension::<AuthenticatedUser>() {
            Some(user) => user,
            None => return Box::pin(futures::future::ready(
                Err(Error::from(HttpResponse::Unauthorized().finish()))
            )),
        };

        // Check if this route requires specific permissions
        let path = req.match_pattern().unwrap_or("");
        let required_role = match path {
            "/admin" => Some("admin"),
            "/user/profile" => Some("user"),
            _ => None,
        };

        if let Some(role) = required_role {
            if user.role != role {
                return Box::pin(futures::future::ready(
                    Ok(req.into_response(
                        HttpResponse::Forbidden().finish()
                    ))
                ));
            }
        }

        // Add user to request extensions for handler access
        req.extensions_mut().insert(user);

        let fut = self.service.call(req);
        Box::pin(fut)
    }
}

// Usage in main
#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .wrap(AuthenticationMiddleware)
            .wrap(AuthorizationMiddleware)
            .service(web::resource("/admin")
                .to(admin_handler))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

async fn admin_handler(
    user: AuthenticatedUser, // Extracted by FromRequest
) -> impl Responder {
    // User is already authorized by middleware
    HttpResponse::Ok().json({"message": "Admin access granted"})
}

For object-level authorization, use request-scoped data to validate resource ownership:

async fn update_own_post(
    id: web::Path<u32>,
    form: web::Json<UpdatePost>,
    user: AuthenticatedUser,
    data: web::Data<AppState>
) -> impl Responder {
    
    // Verify ownership before allowing update
    let post_owner = data.db.get_post_owner(id.into_inner()).await;
    
    match post_owner {
        Ok(owner_id) if owner_id == user.user_id => {
            let result = data.db.update_post(id.into_inner(), form.0).await;
            match result {
                Ok(_) => HttpResponse::Ok().finish(),
                Err(_) => HttpResponse::InternalServerError().finish()
            }
        }
        _ => HttpResponse::Forbidden().finish(),
    }
}

The key principle is ensuring authorization checks happen before any business logic executes, and that user context is properly propagated through async operations using request extensions or similar mechanisms.