Rate Limiting Bypass in Axum with Jwt Tokens

A Rate Limiting Bypass in Axum using JWT tokens typically occurs when rate limiting is applied only to unauthenticated paths or to a coarse identifier such as IP address, while token-based authentication is not consistently included in the limiting key. In this configuration, an authenticated user can make many requests within a short window because each request carries a different valid JWT containing the same user identity. The server may treat each token as a distinct context and fail to associate them with a shared rate limit bucket for the underlying user or client. This allows an attacker who compromises a single account or who can generate multiple tokens to exceed intended request caps without triggering defenses.

Additionally, if the rate limiting implementation inspects only path or IP and does not reliably extract and normalize the subject (sub) claim from the JWT, two different tokens representing the same user may be rate limited independently. Inconsistent token parsing, such as failing to handle token formats with the same payload but different encodings or issuers, can further weaken the limiting logic. Because the application trusts the token scope to enforce identity, missing canonicalization of claims leads to a split-bucket effect where the effective limit per user is multiplied by the number of distinct tokens they can obtain. This is especially relevant when token lifetimes are long or when refresh flows issue new tokens without revoking prior ones.

Real-world attack patterns mirror API abuse scenarios cataloged in the OWASP API Security Top 10, including excessive data consumption and broken object level authorization when rate limits are weak. A scanner that tests unauthenticated surfaces and then validates authenticated behavior using JWT tokens can surface these inconsistencies by submitting requests with varied tokens but identical user contexts. Findings often highlight missing normalization of the sub claim, lack of binding between token identity and rate limit buckets, and absence of coordinated limits across authentication and unauthenticated routes. Remediation focuses on designing a stable, token-aware rate limiting key, canonicalizing claims, and ensuring that limits apply to the underlying user or client rather than to ephemeral tokens alone.

To mitigate Rate Limiting Bypass in Axum when JWT tokens are used, implement rate limiting on a stable user identifier extracted and canonicalized from the token claims. Prefer the sub claim for user identity, and ensure the same normalization logic is applied across all endpoints. Below are concrete, working Axum examples that demonstrate how to structure the middleware and route handling to bind rate limits to the user rather than to the token or IP.

Consistent JWT extraction and claim normalization

Define a helper that decodes the token, validates required fields, and returns a canonical user key. This avoids variations caused by issuer differences or encoding differences for the same subject.

use axum::{async_trait, extract::{FromRequest, RequestParts}};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use serde::{Deserialize, Serialize};
use std::{convert::Infallible, sync::Arc};

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    exp: usize,
    iss: String,
}

struct UserId(String);

#[async_trait]
impl FromRequest<S> for UserId
where
    S: Send + Sync,
{
    type Rejection = Infallible;

    async fn from_request(req: &mut RequestParts<S>) -> Result<Self, Self::Rejection> {
        let auth = req.headers().get("authorization")
            .and_then(|v| v.to_str().ok())
            .and_then(|s| s.strip_prefix("Bearer "))
            .unwrap_or("");

        let token_data = decode::

use axum::{middleware::Next, response::Response, Extension, Json};
use std::collections::HashMap;
use std::sync::{Arc, Mutex};

#[derive(Clone)]
struct RateLimiter {
    limits: Arc<Mutex<HashMap<String, (usize, std::time::Instant)>>>,
    max_requests: usize,
    window: std::time::Duration,
}

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

    fn allow(&self, user_id: &str) -> bool {
        let mut map = self.limits.lock().unwrap();
        let entry = map.entry(user_id.to_string()).or_insert((0, self.window.instant()));
        if entry.1.elapsed() > self.window {
            entry.0 = 1;
            entry.1 = self.window.instant();
            true
        } else if entry.0 < self.max_requests {
            entry.0 += 1;
            true
        } else {
            false
        }
    }
}

async fn rate_limit_middleware(
    UserId(user_id): UserId,
    limiter: Extension<RateLimiter>,
    next: Next,
) -> Response {
    if limiter.allow(&user_id) {
        next.run().await
    } else {
        Response::builder()
            .status(429)
            .body("Too Many Requests".into())
            .unwrap()
    }
}

use axum::{routing::get, Router};

let limiter = RateLimiter::new(100, std::time::Duration::from_secs(60));
let app = Router::new()
    .route("/profile", get(|| async { "ok" }))
    .layer(Extension(limiter))
    .layer(axum::middleware::from_fn_with_state(
        (),
        rate_limit_middleware,
    ));