Brute Force Attack in Actix with Api Keys

A brute force attack against an Actix web service that relies solely on API keys for authentication occurs when an attacker attempts many key values in rapid succession to discover a valid key. Because Actix does not inherently enforce account lockouts or escalating delays for repeated authentication failures, an unauthenticated endpoint that accepts an API key in a header (e.g., x-api-key) can be probed without triggering defensive responses. In this scenario, the API key is the single factor; if the key space is insufficiently large or the key is derived from predictable information, automated tools can iterate through candidate keys or use leaked key patterns to find a match.

Actix applications often expose this risk when routes are permissive in terms of methods and CORS, and when rate limiting is absent or applied after authentication rather than at the edge. Without middleware that validates the key on each request and enforces throttling per client or per key, each attempt appears as a legitimate request to the server. This enables attackers to perform high-volume requests within the scan window (5–15 seconds), testing many keys against endpoints such as /admin/users or /export/data. Findings from such scans typically highlight weak key entropy, missing rate limiting, and excessive data exposure when a valid key is discovered, mapping to OWASP API Top 10 controls like broken object level authorization and insufficient brute force protection.

In a black-box scan, middleBrick tests this attack surface by probing endpoints with invalid and malformed keys, observing response differentials (e.g., 200 vs 403), and checking whether responses leak information that facilitates further guessing. Because the scan is unauthenticated and runs in 5–15 seconds, it can identify whether an Actix service allows unlimited key trials and whether responses differ based on key validity. These observations are surfaced as actionable findings with severity ratings and remediation guidance, helping teams understand how an attacker might escalate from discovery to data exposure.

To mitigate brute force risks for API keys in Actix, enforce server-side rate limiting, validate key format before business logic, and ensure consistent timing for valid and invalid key attempts. Below are concrete, realistic examples that you can adapt to your Actix service.

1. Rate limiting with token bucket using actix-web middleware

Use a middleware that tracks requests per key and enforces a threshold. This example uses actix-web middleware with std::collections::HashMap and std::time::Instant for simplicity; in production, consider a distributed store like Redis for multi-instance deployments.

use actix_web::{dev::ServiceRequest, Error, HttpMessage};
use actix_web_httpauth::extractors::bearer::BearerAuth;
use std::collections::HashMap;
use std::sync::{Arc, Mutex};
use std::time::{Duration, Instant};

struct RateLimiter {
    limits: HashMap>,
    max_requests: usize,
    window: Duration,
}

impl RateLimiter {
    fn new(max_requests: usize, window: Duration) -> Self {
        Self { limits: HashMap::new(), max_requests, window }
    }

    fn allow(&mut self, key: &str) -> bool {
        let now = Instant::now();
        let requests = self.limits.entry(key.to_string()).or_default();
        requests.retain(|t| now.duration_since(*t) < self.window);
        if requests.len() < self.max_requests {
            requests.push(now);
            true
        } else {
            false
        }
    }
}

// Wrap in Arc<Mutex<..>> and share via Data<..> in Actix app data
async fn validate_key_middleware(
    req: ServiceRequest,
    key: String,
    limiter: actix_web::web::Data<Arc<Mutex<RateLimiter>>>
) -> Result<ServiceRequest, Error> {
    let mut limiter = limiter.lock().unwrap();
    if limiter.allow(&key) {
        Ok(req)
    } else {
        Err(actix_web::error::ErrorTooManyRequests("Rate limit exceeded"))
    }
}

// Example route using bearer-like key via header
async fn protected_route(
    key_auth: actix_web_httpauth::extractors::bearer::BearerAuth,
) -> String {
    format!("Authenticated as: {}", key_auth.token())
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    use actix_web::{web, App, HttpResponse, HttpServer};
    let limiter = web::Data::new(Arc::new(Mutex::new(RateLimiter::new(10, Duration::from_secs(60)))));

    HttpServer::new(move || {
        App::new()
            .app_data(limiter.clone())
            .route("/api/data", web::get().to(protected_route))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

2. Constant-time key comparison to prevent timing attacks

When validating an API key, avoid early exit comparisons that reveal validity via timing differences. Use a constant-time equality check or ensure validation logic does not branch on secret data. Below is an example of comparing a provided key against stored keys in a way that reduces timing leakage.

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

// Simulated stored key (in practice, load from secure config)
const STORED_KEY: &[u8; 32] = &[0u8; 32];

fn validate_api_key_provided(input: &str) -> bool {
    // Expect hex-encoded 256-bit key for constant-time comparison
    if let Ok(decoded) = hex::decode(input) {
        if decoded.len() == 32 {
            let decoded_arr: [u8; 32] = decoded.try_into().unwrap_or([0u8; 32]);
            return STORED_KEY.ct_eq(&decoded_arr).into();
        }
    }
    // Still perform a dummy constant-time comparison to avoid branching
    let dummy: [u8; 32] = [1u8; 32];
    STORED_KEY.ct_eq(&dummy).into()
}

#[post("/api/secure")]
async fn secure_endpoint(
    body: web::Json<serde_json::Value>
) -> HttpResponse {
    let provided = body.get("api_key").and_then(|v| v.as_str()).unwrap_or("");
    if validate_api_key_provided(provided) {
        HttpResponse::Ok().body("Access granted")
    } else {
        HttpResponse::Forbidden().body("Invalid key")
    }
}

3. Enforce key format and reject malformed requests early

Validate the structure of the API key before using it in lookup logic. This reduces unnecessary processing and ensures that malformed inputs do not bypass controls.

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

fn is_valid_key_format(key: &str) -> bool {
    // Example: 32-byte hex string
    key.len() == 64 && key.chars().all(|c| c.is_ascii_hexdigit())
}

async fn handler_with_format_check(
    web::Header(key): web::Header<String>
) -> Result<HttpResponse> {
    if !is_valid_key_format(&key) {
        return Ok(HttpResponse::BadRequest().body("Invalid key format"));
    }
    // Proceed with key validation
    Ok(HttpResponse::Ok().body("OK"))
}