Security Misconfiguration in Actix with Bearer Tokens

In Actix web applications, a common security misconfiguration occurs when Bearer token authentication is enabled without enforcing HTTPS and without validating the Authorization header format and scope. This combination exposes APIs to token leakage and unauthorized access. For example, if an Actix service accepts Bearer tokens over HTTP, tokens can be intercepted in transit. Additionally, missing validation of the token format (e.g., allowing malformed tokens or failing to reject tokens without the required scopes) can lead to BOLA/IDOR-like issues where one actor assumes the identity of another.

Actix routes often define guards or extractors that pull the Bearer token from the header, but if these extractors are applied inconsistently across endpoints, some routes remain unauthenticated. This creates an unauthenticated attack surface that middleBrick flags as a security risk during black-box scanning. The scanner tests whether protected endpoints correctly reject requests without a valid Bearer token and whether tokens are accepted only over encrypted channels. Without transport-layer enforcement, tokens may be logged in server access logs or exposed via referrer headers, leading to Data Exposure findings.

Another misconfiguration involves overly permissive CORS policies paired with Bearer token usage. If an Actix app responds to preflight requests with broad origins and allows credentials, a malicious site can make authenticated requests on behalf of a victim. This can facilitate SSRF or token exfiltration when combined with improperly scoped tokens. middleBrick’s checks for Encryption and Authentication highlight these gaps by verifying that responses include strict transport security headers and that token validation occurs before routing logic.

The scanner also tests for Missing or Broken Rate Limiting on authenticated routes. When Bearer token validation is implemented but rate limits are absent or misconfigured, attackers can perform brute-force or enumeration attacks on token validity. This may expose patterns in token issuance or allow token reuse across accounts, which violates proper Inventory Management and Property Authorization controls. Each of these misconfigurations contributes to a higher risk score and findings mapped to frameworks such as OWASP API Top 10 and SOC2 controls.

To remediate Bearer token misconfigurations in Actix, enforce HTTPS, validate token format, and apply authentication consistently across all protected routes. Below is a minimal, secure Actix implementation that demonstrates these fixes. This example uses the actix-web framework and assumes a middleware or extractor validates the token against an authorization service.

use actix_web::{web, App, HttpServer, HttpResponse, HttpRequest, middleware::Logger};
use actix_web::http::header::HeaderValue;
use actix_web::dev::{Service, ServiceRequest, ServiceResponse, Transform};
use actix_web::error::ErrorUnauthorized;
use futures::future::{ok, Ready};

// A simple extractor that validates Bearer token presence and format
async fn validate_bearer_token(req: &HttpRequest) -> Result {
    let auth_header = req.headers().get("Authorization")
        .ok_or_else(|| ErrorUnauthorized("Missing Authorization header"))?;
    let auth_str = auth_header.to_str().map_err(|_| ErrorUnauthorized("Invalid header encoding"))?;
    if !auth_str.starts_with("Bearer ") {
        return Err(ErrorUnauthorized("Invalid Authorization scheme"));
    }
    let token = auth_str[7..].trim();
    if token.is_empty() {
        return Err(ErrorUnauthorized("Token is empty"));
    }
    // Here you would integrate with a token validation service or JWT verification
    Ok(token.to_string())
}

// Middleware to enforce HTTPS in production
struct HttpsEnforce;

impl Transform for HttpsEnforce
where
    S: Service, Error = actix_web::Error>,
    S::Future: 'static,
{
    type Response = ServiceResponse;
    type Error = actix_web::Error;
    type InitError = ();
    type Transform = HttpsEnforceMiddleware;
    type Future = Ready>;

    fn new_transform(&self, service: S) -> Self::Future {
        ok(HttpsEnforceMiddleware { service })
    }
}

struct HttpsEnforceMiddleware {
    service: S,
}

impl Service for HttpsEnforceMiddleware
where
    S: Service, Error = actix_web::Error>,
{
    type Response = ServiceResponse;
    type Error = actix_web::Error;
    type Future = S::Future;

    fn poll_ready(&self, cx: &mut std::task::Context<'_>) -> std::task::Poll> {
        self.service.poll_ready(cx)
    }

    fn call(&self, req: ServiceRequest) -> Self::Future {
        // In real deployment, terminate TLS at load balancer and set X-Forwarded-Proto
        // For illustration, we assume HTTPS is enforced upstream
        self.service.call(req)
    }
}

async fn protected_route(req: HttpRequest) -> HttpResponse {
    match validate_bearer_token(&req).await {
        Ok(_) => HttpResponse::Ok().body("Access granted"),
        Err(_) => HttpResponse::Unauthorized().body("Invalid token"),
    }
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    env_logger::init_from_env(env_logger::Env::new().default_filter_or("info"));
    HttpServer::new(|| {
        App::new()
            .wrap(Logger::default())
            .wrap(HttpsEnforce)
            .route("/api/secure", web::get().to(protected_route))
    })
    .bind("0.0.0.0:8443")?
    .run()
    .await
}