Token Replay in Actix (Rust)

Token replay in Actix applications using Rust typically occurs when a bearer token (such as a JWT) is accepted without additional context validation, allowing an attacker to capture a valid token and reuse it in a subsequent request. In Rust-based Actix services, this risk arises when APIs rely solely on the presence and signature of a token, without enforcing per-request or per-session uniqueness checks such as a nonce, timestamp, or one-time use constraint.

The combination of Actix's asynchronous, actor-based routing and Rust's type safety can inadvertently encourage developers to focus on authentication correctness while overlooking replay-specific defenses. For example, an endpoint that only verifies a JWT's validity and extracts claims is vulnerable if the same Authorization header can be forwarded or replayed hours later to perform sensitive actions like changing an email or initiating a payment. MiddleBrick’s authentication checks flag this as a BOLA/IDOR-related risk when token usage is not bound to a specific request context.

In Rust, developers might use extractor patterns such as web::Json with a custom guard that validates tokens but does not track usage. Because Actix processes requests concurrently across multiple workers, an attacker who intercepts a token can replay it to any worker, and the service may still treat it as valid. Without server-side state or a replay cache (e.g., a short-lived Bloom filter or a per-user nonce store), there is no mechanism to detect reuse. MiddleBrick’s tests include scenarios where the same token is used across distinct requests, and findings are mapped to the Authentication and BOLA/IDOR categories with severity and remediation guidance.

Real-world attack patterns such as captured tokens from logs, browser history, or insecure mobile storage can lead to replay. For instance, if a token contains a "sub" claim but no jti (JWT ID) or timestamp freshness check, an attacker can reuse it indefinitely. The OWASP API Top 10 and related frameworks highlight these classes of flaws under broken object level authorization and insufficient anti-replay controls. MiddleBrick’s scans detect such conditions during unauthenticated black-box testing, providing a security risk score and prioritized findings.

To mitigate token replay in Actix services written in Rust, you should bind token usage to request-specific context and avoid treating tokens as purely static credentials. Below are concrete patterns and code examples that demonstrate how to implement replay-resistant validation within an Actix-web application.

First, include a jti (JWT ID) claim in your tokens and maintain a short-lived cache of recently seen identifiers. Using actix-web extractors and std::collections::HashSet protected by Mutex or a concurrent structure like dashmap::DashMap, you can reject replays within the cache window.

use actix_web::{dev::ServiceRequest, Error, HttpMessage};
use actix_web::http::header::AUTHORIZATION;
use actix_web::web::Data;
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use std::collections::HashSet;
use std::sync::{Arc, Mutex};
use std::time::{SystemTime, UNIX_EPOCH};

struct Claims {
    sub: String,
    jti: String,
    exp: usize,
}

async fn validate_token(req: ServiceRequest) -> Result {
    let auth_header = req.headers().get(AUTHORIZATION)
        .ok_or_else(|| actix_web::error::ErrorUnauthorized("missing authorization header"))?;
    let token = auth_header.to_str().unwrap_or("").trim_start_matches("Bearer ");

    // In production, use a shared cache such as DashMap for higher throughput
    static REPLAY_CACHE: OnceLock>>> = OnceLock::new();
    let cache = REPLAY_CACHE.get_or_init(|| Arc::new(Mutex::new(HashSet::new())));

    let validation = Validation::new(Algorithm::HS256);
    let token_data = decode::(token, &DecodingKey::from_secret("your-secret".as_ref()), &validation)
        .map_err(|_| actix_web::error::ErrorUnauthorized("invalid token"))?;

    let mut cache = cache.lock().unwrap();
    if cache.contains(&token_data.claims.jti) {
        return Err(actix_web::error::ErrorUnauthorized("replayed token detected"));
    }
    // Keep cache bounded in production; this is a simplified example
    cache.insert(token_data.claims.jti.clone());

    req.extensions_mut().insert(token_data.claims);
    Ok(req)
}

// Example of contextual validation including method and path
async fn contextual_guard(req: &ServiceRequest) -> Result<(), Error> {
    let claims = req.extensions().get::()
        .ok_or_else(|| actix_web::error::ErrorForbidden("claims missing"))?;
    let method = req.method();
    let path = req.path();

    // Reject replays across different paths or methods even with valid token
    if (method == &Method::POST && path.starts_with("/transfer")) && !claims.scopes.contains("transfer") {
        return Err(actix_web::error::ErrorForbidden("insufficient scope"));
    }
    // Add additional business rules here
    Ok(())
}