Brute Force Attack in Actix with Bearer Tokens

A brute force attack against an Actix web service that uses Bearer tokens attempts to discover valid tokens by systematically trying many candidate values. Because Bearer tokens are typically passed in the Authorization header, an attacker can target the login or token validation endpoints, or any route that accepts a token, without needing to break cryptographic algorithms. The presence of Actix does not inherently prevent this; if rate limiting is absent or too permissive, an attacker can send many requests with different tokens in a short period, increasing the chance of guessing a valid token or causing account lockouts or service disruption.

When authentication relies on bearer tokens without additional protections, the attack surface includes both online and offline scenarios. Online brute force occurs against the API endpoint itself—such as /login or /validate—where each request is checked against a backend identity store. Offline scenarios may arise if token generation is predictable or if leaked token data allows offline guessing or replay. Actix applications that do not enforce per-user or per-client rate limits, or that return distinct responses for valid versus invalid tokens, inadvertently aid attackers by providing observable feedback that guides the brute force process.

Common misconfigurations that amplify risk include missing account lockout policies, lack of exponential backoff, and absence of one-time tokens or CAPTCHA challenges after suspicious behavior. In distributed deployments behind load balancers, if rate limiting is implemented only at the edge or in a shared cache, an attacker can bypass protections by rotating source IPs. Furthermore, if logging inadvertently exposes tokens or reveals timing differences between valid and invalid checks, additional information leakage may support more efficient brute force campaigns. The combination of Actix routing with Bearer token authentication therefore requires deliberate controls to ensure that token validation does not become an easy target for automated guessing attacks.

Remediation focuses on rate limiting, token validation hygiene, and reducing information leakage. Implement per-user or per-client rate limits, use constant-time comparison for token validation, and standardize error responses to avoid signaling whether a token is partially valid. The following Actix-web examples illustrate these practices in Rust.

1. Rate limiting with actix-web and redis-backed sliding window

This example uses actix-web middleware and a Redis-based rate limiter to restrict the number of authentication attempts per user identifier extracted from the Bearer token or from the request IP.

use actix_web::{web, App, HttpServer, HttpRequest, HttpResponse, Error};
use actix_web_httpauth::extractors::bearer::BearerAuth;
use redis::AsyncCommands;
use std::time::Duration;

async fn login_rate_limiter(
    req: HttpRequest,
    auth: Option,
) -> Result<(), Error> {
    let client = redis::Client::open("redis://127.0.0.1/")?;
    let mut conn = client.get_async_connection().await?;
    // Identify by user if token is present, otherwise by IP
    let key = match auth.map(|a| a.token().to_string()) {
        Some(token) => format!("rl:user:{token}"),
        None => format!("rl:ip:{}", req.connection_info().realip_remote_addr().unwrap_or("unknown")),
    };
    let current: u64 = conn.get(&key).await.unwrap_or(0);
    if current >= 10 {
        return Err(actix_web::error::ErrorTooManyRequests("rate limit exceeded"));
    }
    conn.set_ex(&key, current + 1, Duration::from_secs(60)).await?;
    Ok(())
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .wrap_fn(|req, srv| {
                let fut = login_rate_limiter(req.clone(), req.headers().get("Authorization").and_then(|v| v.to_str().ok()).and_then(|s| s.strip_prefix("Bearer ")).map(|t| t.to_string()).map(BearerAuth::from)));
                async { fut.await.map(|()| srv.call(req).await?) }
            })
            .route("/login", web::post().to(|| async { HttpResponse::Ok().finish() }))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

2. Constant-time token validation to prevent timing leaks

Avoid branching on token validity before comparison. Use a constant-time equality check so that response times do not reveal information about partial matches.

use actix_web::{web, HttpResponse};
use subtle::ConstantTimeEq;

async fn validate_token(headers: web::Header<actix_web_httpauth::headers::authorization::Bearer>) -> HttpResponse {
    let expected = b"supersecretvalue123"; // In practice, fetch from secure store per user
    let provided = headers.token().as_bytes();
    // Use constant-time comparison
    let valid = expected.ct_eq(provided).unwrap_or(0) == 1 && provided.len() == expected.len();
    if valid {
        HttpResponse::Ok().body("Authenticated")
    } else {
        // Always return the same generic error and status code
        HttpResponse::Unauthorized().body("Invalid credentials")
    }
}

3. Standardized error responses and avoiding token leakage in logs

Ensure that error messages do not distinguish between missing, malformed, and invalid tokens. Also avoid logging full tokens; if logging is necessary, redact or hash them.

// Bad: reveals token presence via timing or log patterns
// Good: uniform handling
async fn handle_auth_error() -> HttpResponse {
    // Log with token redaction
    // logger::warn!(token = "**REDACTED**", "authentication attempt failed");
    HttpResponse::Unauthorized()
        .json(serde_json::json!({ "error": "invalid_token", "message": "Authentication failed" }))
}

4. Complementary protections: short-lived tokens and rotation

Use short expiration times and refresh token rotation to limit the impact of token compromise. Even if an attacker performs brute force, the window of validity is small. Store refresh tokens securely and bind them to client metadata where feasible.