Brute Force in Axum (Rust)

Brute force attacks against HTTP APIs often target authentication endpoints by submitting many credential guesses. In an Axum service written in Rust, the combination of permissive route design, missing attempt tracking, and unchecked request bodies can expose login or token endpoints to credential guessing. Axum does not enforce authentication semantics on its own; you build them. If those controls do not limit attempts or require progressive delays, an attacker can iterate over passwords or tokens without effective friction.

When designing login routes in Axum, a typical handler receives credentials from a JSON body, validates them, and issues a session or token. Without explicit attempt counting, IP or account-based throttling, and secure password storage (e.g., Argon2id), the endpoint becomes a practical target for online brute force. Attackers may use low-and-slow patterns to avoid simple threshold-based protections. Even with HTTPS, leaked credentials can lead to account takeover, especially if multi-factor authentication (MFA) is absent or optional.

Rate limiting in Axum is commonly implemented via middleware or wrappers around the router. If limits are applied globally rather than per-username or per-identifier, attackers can rotate through many accounts and remain under the threshold. Additionally, inconsistent response behavior—such as returning different status codes for missing users versus incorrect passwords—can aid enumeration. The framework does not prescribe how to handle enumeration safely; developers must ensure uniform delays and responses to prevent user account discovery.

Logging and observability can inadvertently assist attackers if failed attempts are recorded with precise timestamps and usernames without adequate protection. In Rust, structured logging with tools like tracing is common; if logs contain raw identifiers and are aggregated centrally, they can be mined to prioritize high-value targets. Axum applications that stream structured events to monitoring systems should ensure sensitive metadata is masked or rate-limited to avoid exposing patterns that facilitate automated guessing.

Because Axum is unopinionated about authentication, developers must integrate protections explicitly. Security scans from middleBrick often flag weak authentication controls and enumerate findings tied to Authentication, BOLA/IDOR, and Rate Limiting. By combining runtime scans with spec analysis, the tool can correlate design choices in your OpenAPI definition with observed behavior, helping you identify whether brute force protections are consistently applied across endpoints handling credentials.

Remediation focuses on limiting attempts, introducing delays, protecting identifiers, and using strong password storage. Below are concrete, idiomatic Axum examples in Rust that address brute force risks.

1. Rate limiting per user or IP using tower middleware and a sliding window store. This example uses tower::ServiceBuilder with a custom rate limiter state shared across workers.

use axum::{routing::post, Router};
use std::net::SocketAddr;
use tower_http::limit::RateLimitLayer;
use std::sync::Arc;
use async_trait::async_trait;
use std::collections::HashMap;
use std::time::{Duration, Instant};
use tokio::sync::RwLock;

struct SlidingWindowStore {
    // map identifier to recent request timestamps
    attempts: HashMap>,
}

impl SlidingWindowStore {
    fn new() -> Self {
        Self { attempts: HashMap::new() }
    }

    fn record(&mut self, key: String) -> bool {
        let now = Instant::now();
        let window = Duration::from_secs(60);
        let max = 5; // allow 5 attempts per window
        let entry = self.attempts.entry(key).or_default();
        entry.retain(|t| now.duration_since(*t) < window);
        if entry.len() >= max {
            return false;
        }
        entry.push(now);
        true
    }
}

#[tokio::main]
async fn main() {
    let store = Arc::new(RwLock::new(SlidingWindowStore::new()));
    let rate_limit = RateLimitLayer::new(100, Duration::from_secs(60)) // global fallback
        .with_store(store);

    let app = Router::new()
        .route("/login", post(login_handler))
        .layer(rate_limit);

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

async fn login_handler() -> &'static str {
    "implemented"
}

2. Uniform response behavior and progressive delay. Return a generic authentication failure message and apply incremental sleep for repeated failures on the same identifier.

use axum::{response::IntoResponse, Json};
use serde::Deserialize;
use std::time::Instant;
use tokio::time::{sleep, Duration};

#[derive(Deserialize)]
struct Credentials {
    username: String,
    password: String,
}

async fn validate_credentials(username: &str, password: &str) -> bool {
    // Use a constant-time comparison where feasible and Argon2id for storage
    false
}

async fn login_handler(Json(payload): Json<Credentials>) -> impl IntoResponse {
    let username = payload.username.clone();
    let failures_key = format!("fail:{}", username);
    // In practice, use a shared KV store (e.g., Redis) with TTL
    static mut FAIL_TIMES: Option<std::collections::HashMap<String, Vec<Instant>>> = None;
    unsafe {
        if FAIL_TIMES.is_none() {
            FAIL_TIMES = Some(std::collections::HashMap::new());
        }
        let times = FAIL_TIMES.as_mut().unwrap();
        let window_start = Instant::now() - Duration::from_secs(300);
        let entry = times.entry(failures_key.clone()).or_default();
        entry.retain(|&t| t >= window_start);
        if entry.len() >= 3 {
            let delay = Duration::from_secs(1u64.saturating_add(entry.len() as u64));
            sleep(delay).await;
        }
        if validate_credentials(&username, &payload.password).await {
            entry.clear();
            ("Login successful", [( "HTTP/1.1 200 OK"), ("Content-Type", "application/json")]).into_response()
        } else {
            entry.push(Instant::now());
            ("Authentication failed", [( "HTTP/1.1 401 Unauthorized"), ("Content-Type", "application/json")]).into_response()
        }
    }
}

3. Password storage and hashing. Use Argon2id via password_hash crate to store credentials safely and prevent offline recovery if data leaks.

use argon2::{self, Config, ThreadMode, Variant, Version};
use rand_core::OsRng;
use std::fmt;

fn hash_password(plain: &str) -> Result<String, argon2::Error> {
    let config = Config::new(Variant::Argon2id, Version::Version13, ThreadMode::Parallel, 1, 65536, 4)?;
    let salt = b"unique-per-user-salt"; // in practice, generate a random salt per user
    let mut out = String::new();
    argon2::hash_encoded(plain.as_bytes(), salt, &config, &mut out)?;
    Ok(out)
}

fn verify_password(plain: &str, hash: &str) -> bool {
    argon2::verify_encoded(hash, plain.as_bytes()).unwrap_or(false)
}

4. Secure observability. Avoid logging raw usernames on failure; use a token or salted hash when necessary for debugging.

use tracing::info;
fn audit_failure(user_handle: &str) {
    // Avoid logging raw username; use a consistent non-identifiable token
    let token = sha2::Sha256::digest(user_handle.as_bytes());
    info!(user_token = ?token, "auth failure");
}

middleBrick can help by scanning your endpoints and mapping findings to frameworks like OWASP API Top 10 and PCI-DSS. Its per-category breakdowns highlight Authentication, Rate Limiting, and Data Exposure issues, and the CLI allows you to integrate checks into scripts so you can iterate on fixes and re-scan to verify improvements.