Brute Force Attack in Axum with Jwt Tokens

A brute force attack against an Axum service that uses JWT tokens attempts to discover valid tokens or secrets by systematically trying many values. Because JWTs often carry authentication or authorization meaning, attackers focus on two vectors: token guessing and secret/key guessing.

In Axum, if routes that accept JWT tokens do not enforce strict rate limits per identity or origin, an attacker can send many authorization requests containing guessed tokens or missing/invalid tokens. Without per-user or per-client throttling, the server processes each attempt quickly, enabling high-volume trials. JWTs with low-entropy secrets or weak signing algorithms (e.g., HS256 with a short dictionary word) make offline guessing feasible if an attacker can obtain a token signature or public endpoint behavior. Additionally, if introspection or public-key validation logic in Axum does not consistently enforce token validity checks, an attacker may exploit timing differences or error messages to infer whether a guessed token is structurally valid.

Another scenario involves unauthenticated endpoints that reveal user existence or account status when combined with token manipulation. For example, an endpoint that returns different behavior based on a missing or malformed JWT can allow enumeration that supports targeted brute force. Because JWTs include claims like iss, sub, or roles, attackers may iterate through plausible subject identifiers or issuers to locate valid token-subject pairings.

Without proper controls, brute force against JWT-protected Axum endpoints can lead to unauthorized access, privilege escalation, or token replay. The attack surface is larger when tokens have long lifetimes, when secrets are shared across services, or when logs inadvertently expose tokens.

To mitigate brute force risks for JWT tokens in Axum, combine strong token design, strict validation, per-identity rate limiting, and observability without exposing sensitive information.

1. Use strong signing keys and algorithms

Prefer asymmetric algorithms like RS256 and keep private keys protected. Do not use weak secrets.

use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use axum::extract::Request;
use std::sync::Arc;

// Load a PEM-encoded RSA public key for verification
let public_key = include_str!("/path/to/public.key");
let decoding_key = DecodingKey::from_rsa_pem(public_key.as_bytes()).expect("valid PEM");

let mut validation = Validation::new(Algorithm::RS256);
validation.validate_exp = true;
validation.validate_nbf = true;
// Enforce issuer and audience when applicable
validation.set_issuer(&["https://auth.example.com"]);
validation.set_audience(&["api.example.com"]);

// In an extractor or middleware:
async fn validate_token(req: Request, body: B) -> Result<..., (StatusCode, String)> {
    let auth_header = req.headers().get("authorization")
        .ok_or((StatusCode::UNAUTHORIZED, "missing authorization header"))?;
    let token = auth_header.to_str().map_err(|_| (StatusCode::UNAUTHORIZED, "invalid header format"))?
        .strip_prefix("Bearer ")
        .ok_or((StatusCode::UNAUTHORIZED, "invalid bearer format"))?;

    let token_data = decode::(token, &decoding_key, &validation)
        .map_err(|e| (StatusCode::UNAUTHORIZED, format!("invalid token: {}", e)))?;
    Ok((token_data.claims, body)) // or attach to request extensions
}

use std::collections::HashMap;
use std::sync::{Arc, Mutex};
use axum::extract::State;

struct RateLimiter {
    // Map from subject or issuer to (last_request_time, request_count)
    limits: Mutex>,
}

impl RateLimiter {
    fn allow(&self, key: &str, max_requests: u32, window: std::time::Duration) -> bool {
        let mut map = self.limits.lock().unwrap();
        let entry = map.entry(key.to_string()).or_insert((std::time::Instant::now(), 0));
        if entry.0.elapsed() > window {
            entry.0 = std::time::Instant::now();
            entry.1 = 0;
        }
        if entry.1 < max_requests {
            entry.1 += 1;
            true
        } else {
            false
        }
    }
}

// Share state via Arc
let limiter = Arc::new(RateLimiter { limits: Mutex::new(HashMap::new()) });

async fn login_or_token_route(
    State(limiter): State<Arc<RateLimiter>>,
    Json(payload): Json<LoginPayload>,
) -> Result<Json<Value>, (StatusCode, String)> {
    let key = if let Some(sub) = &payload.subject {
        sub.clone()
    } else {
        // fallback to IP or a composite key in absence of sub
        format!("ip:{}", std::net::IpAddr::from([127,0,0,1]))
    };
    if !limiter.allow(&key, 5, std::time::Duration::from_secs(60)) {
        return Err((StatusCode::TOO_MANY_REQUESTS, "rate limit exceeded".into()));
    }
    // proceed with login or token validation
    Ok(Json(json!({ "ok": true })))
}

async fn auth_middleware(req: Request, next: Next<B>) -> Result<impl IntoResponse, (StatusCode, String)> {
    let token = match extract_token(&req) {
        Ok(t) => t,
        Err(_) => return Err((StatusCode::UNAUTHORIZED, "invalid request".into())),
    };
    // Perform decode/validation; on failure always return the same generic response
    match validate_jwt(&token).await {
        Ok(claims) => Ok(next.run(req).map(|res| res)),
        Err(_) => Err((StatusCode::UNAUTHORIZED, "invalid request".into())),
    }
}