Brute Force Attack in Axum with Api Keys

A brute force attack against an Axum service that relies exclusively on API keys for authentication leverages two factors: predictable or leaked keys and the absence of rate limiting on key validation endpoints. In Axum, routes are composed around extractor patterns such as State and typed extractors for headers. If an API key is extracted on every request and checked with a synchronous database or cache lookup without any request throttling, an attacker can iterate over many candidate keys rapidly. Because Axum is often deployed behind a gateway or load balancer that terminates TLS, the unauthenticated attack surface remains reachable, and the application may reveal timing differences between a missing key and a malformed key. These timing characteristics can aid online guessing, especially when the key space is not sufficiently large or when keys are derived from weak entropy sources.

The risk is compounded when keys are embedded in URLs or logs, increasing exposure through referrer headers or log aggregation systems. MiddleBrick’s 12 security checks run in parallel and include Authentication, Rate Limiting, and Data Exposure. For an Axum service using API keys, these checks look for missing or weak rate limiting on authentication paths, inconsistent responses that leak whether a key is valid, and any insecure transmission or storage that might expose keys. An OpenAPI/Swagger spec analysis (2.0, 3.0, 3.1) with full $ref resolution can highlight whether the spec documents key rotation or scope restrictions, while runtime findings validate whether those controls are enforced. Without explicit rate limiting and monitoring, an attacker can conduct low-volume, long-duration brute force attempts that evade simple anomaly detection, leading to unauthorized access and potential lateral movement within the system.

Remediation focuses on reducing the attack surface for brute force by combining rate limiting, key validation hygiene, and operational practices. In Axum, you can implement per-key rate limiting using middleware that tracks request counts with token buckets or sliding windows, ensuring that a single key cannot exceed a threshold within a defined period. Additionally, avoid returning different HTTP status codes or response bodies for missing versus invalid keys; use a constant-time validation flow and a generic rejection response to remove timing cues.

Below are concrete Axum examples that demonstrate secure handling of API keys. The first example shows a middleware-based rate limiter integrated into the router, using a State to hold rate limit data and a tower layer to enforce limits before key validation proceeds.

use axum::{routing::get, Router, extract::State};
use std::collections::HashMap;
use std::sync::{Arc, Mutex};
use tower_http::rate_limit::{RateLimitLayer, RateLimitRequestClassifier};
use tower_http::trace::TraceLayer;
use std::time::Duration;

struct RateLimitState {
    // Map key identifier to request count in the current window
    request_counts: HashMap,
    max_requests: u32,
    window: Duration,
}

impl RateLimitState {
    fn new(max_requests: u32, window: Duration) -> Self {
        Self {
            request_counts: HashMap::new(),
            max_requests,
            window,
        }
    }

    fn allow(&mut self, key_id: &str) -> bool {
        let now = std::time::Instant::now();
        let entry = self.request_counts.entry(key_id.to_string()).or_insert((0, now));
        if now.duration_since(entry.1) > self.window {
            entry.0 = 1;
            entry.1 = now;
            true
        } else if entry.0 < self.max_requests {
            entry.0 += 1;
            true
        } else {
            false
        }
    }
}

async fn handler() -> String {
    "OK".to_string()
}

#[tokio::main]
async fn main() {
    let rate_limit_state = Arc::new(Mutex::new(RateLimitState::new(5, Duration::from_secs(60))));
    let app = Router::new()
        .route("/secure", get(handler))
        .layer(RateLimitLayer::new(
            RateLimitRequestClassifier::new_local_address(),
            tower::limit::NoOpKey, // replaced by key-aware classifier in production
        ))
        .with_state(rate_limit_state);

    // axum::Server::bind(&"0.0.0.0:3000".parse().unwrap()).serve(app.into_make_service()).await.unwrap();
}

The second example shows a key extractor that returns a generic error for both missing and invalid keys, avoiding information leakage. It uses a constant-time comparison pattern by checking against stored keys in a hashed form and applying the same validation path regardless of whether the key exists.

use axum::{routing::get, Router, extract::Request, http::StatusCode};
use std::collections::HashMap;
use std::sync::Arc;
use subtle::ConstantTimeEq;

struct ApiKeyState {
    // Store hashed keys; in practice use a slow KDF or HMAC with pepper
    keys: HashMap,
}

async fn api_key_auth(req: Request, State(keys): State>) -> Result {
    let header_value = req.headers().get("X-API-Key")
        .ok_or((StatusCode::UNAUTHORIZED, "Unauthorized".to_string()))?;
    let supplied = header_value.to_str().map_err(|_| (StatusCode::UNAUTHORIZED, "Unauthorized".to_string()))?;

    // Dummy lookup; in production resolve to a hashed key entry
    let stored = keys.keys.get(supplied).ok_or((StatusCode::UNAUTHORIZED, "Unauthorized".to_string()))?;
    let supplied_bytes = supplied.as_bytes();
    // Constant-time compare using stored hash; this example assumes supplied is already a hash for illustration
    let valid = stored.ct_eq(&supplied_bytes[..32]).into();
    if valid {
        Ok("Authorized".to_string())
    } else {
        Err((StatusCode::UNAUTHORIZED, "Unauthorized".to_string()))
    }
}

async fn handler() -> String {
    "success".to_string()
}

#[tokio::main]
async fn main() {
    let keys = ApiKeyState {
        keys: HashMap::new(), // populate with hashed keys
    };
    let app = Router::new()
        .route("/data", get(api_key_auth).then(handler))
        .with_state(Arc::new(keys));

    // axum::Server::bind(&"0.0.0.0:3000".parse().unwrap()).serve(app.into_make_service()).await.unwrap();
}

These examples illustrate how to structure Axum routes and middleware to mitigate brute force risks associated with API keys. Pair these technical controls with regular key rotation, scope minimization, and monitoring for repeated failures, which align with findings reported by security scanning platforms and compliance mappings to frameworks such as OWASP API Top 10 and SOC2.