Api Rate Abuse in Actix with Jwt Tokens

Rate abuse in Actix when JWT tokens are used for authentication can occur when per-identity or per-token rate limits are missing or are applied only after token validation. Without explicit limits tied to the claims inside a JWT, an attacker can make many unauthenticated or low-cost authenticated requests, exhausting server resources or bypassing intended usage caps. For example, if an endpoint only checks that a JWT is well-formed but does not enforce rate limits on the subject or issuer claims, a single leaked token or a token shared among users can be used to trigger excessive requests.

In an Actix web stack, this often manifests when a middleware validates JWT presence but no subsequent rate-limiting logic uses the token’s payload (e.g., sub or custom identifiers). Because Actix routes are permissive by default until guards or guards + guards’ guards are applied, an attacker can probe endpoints at high speed. This is especially risky if token validation is performed in an extractor that does not integrate with a rate-limiting store, allowing token reuse across IPs or behind proxies that obscure source identity.

Consider an authentication flow where a JWT is verified and the user identifier is placed into request extensions for downstream handlers. If the application does not enforce a per-user ceiling, a malicious actor can replay the token to trigger resource-intensive operations or to bypass business logic that assumes bounded usage. Even when IP-based throttling exists, shared IPs (NAT, mobile networks) can cause false negatives, making JWT-based identifiers essential for accurate enforcement.

Because middleBrick tests unauthenticated attack surfaces and checks Authentication and Rate Limiting in parallel, it can surface cases where JWT-secured endpoints lack corresponding rate controls. Findings highlight missing alignment between identity claims and request throttling, providing remediation guidance to map limits to token fields such as sub or a custom scope. The scanner does not fix the service but supplies prioritized findings and actionable guidance so teams can implement token-aware rate limiting.

To remediate rate abuse with JWT tokens in Actix, enforce rate limits using values extracted from the token claims rather than only IP addresses. Below are concrete, syntactically correct examples that show how to validate a JWT and apply per-identity throttling using actix-web, actix-http, and a simple in-memory store for demonstration. In production, replace the in-memory store with a distributed rate limiter (e.g., Redis with token-bucket or sliding-window algorithms).

First, define your claims and a validator that extracts the subject for rate limiting:

use actix_web::{dev::ServiceRequest, Error, http::header::AUTHORIZATION, HttpRequest};
use actix_web_httpauth::extractors::bearer::BearerAuth;
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use serde::{Deserialize, Serialize};
use std::sync::Arc;
use std::time::{SystemTime, UNIX_EPOCH};

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    exp: usize,
    #[serde(rename = "type")]
    typ: String,
}

async fn validate_jwt(req: &ServiceRequest) -> Result {
    let auth = req.headers().get(AUTHORIZATION)
        .and_then(|v| v.to_str().ok())
        .and_then(|s| s.strip_prefix("Bearer "))
        .ok_or_else(|| actix_web::error::ErrorUnauthorized("Missing or malformed Authorization header"))?;

    let token = auth;
    let key = DecodingKey::from_secret("YOUR_SECRET".as_ref());
    let mut validation = Validation::new(Algorithm::HS256);
    validation.validate_exp = true;

    let token_data = decode::(token, &key, &validation)
        .map_err(|_| actix_web::error::ErrorUnauthorized("Invalid token"))?;

    Ok(token_data.claims.sub)
}

Next, implement a lightweight rate limiter keyed by the subject claim. This example uses a dashmap for concurrency and a per-subject sliding window simplified to a per-minute counter:

use dashmap::DashMap;
use std::sync::Arc;
use std::time::{Duration, Instant};

struct RateLimiter {
    limits: DashMap,
    max_requests: usize,
    window: Duration,
}

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

    fn allow(&self, key: String) -> bool {
        let now = Instant::now();
        self.limits
            .entry(key)
            .and_modify(|(count, last)| {
                if now.duration_since(*last) > self.window {
                    *count = 1;
                    *last = now;
                } else {
                    *count += 1;
                }
            })
            .or_insert((1, now));

        if let Some((count, _)) = self.limits.get(&key) {
            *count <= self.max_requests
        } else {
            false
        }
    }
}

// Shared across app data
struct AppState {
    limiter: Arc,
}

Wire the validator and limiter into an Actix guard and a middleware-like extractor. This handler checks the token, enforces limits, and returns 429 when exceeded:

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

async fn protected_handler(
    req: ServiceRequest,
    state: web::Data,
) -> Result {
    let subject = validate_jwt(&req).await?;
    if state.limiter.allow(subject.clone()) {
        Ok(HttpResponse::Ok().body(format!("Hello, {}", subject)))
    } else {
        Err(actix_web::error::ErrorTooManyRequests("Rate limit exceeded"))
    }
}

For broader coverage, apply the limiter in a factory or wrap routes with a custom middleware that runs after JWT validation, ensuring every authenticated request is checked against the token-derived key. This approach aligns rate controls with identity, mitigating token sharing and abuse across users.