Replay Attack in Actix with Api Keys

A replay attack occurs when an attacker intercepts a valid request and retransmits it to reproduce the original effect, such as making a payment or changing a resource state. In Actix web applications that rely solely on API keys for authentication, this vector is particularly relevant because API keys are typically static credentials transmitted with each request. When API keys are sent over unencrypted channels or without additional protections, an attacker who observes a single authenticated request can replay it to the server, and the server will accept it as legitimate because the key remains valid.

The risk is amplified when API keys are used without nonces, timestamps, or idempotency controls. For example, consider an endpoint that transfers funds or updates a configuration. An attacker can capture a request like POST /transfer with a valid API key and identical payload, then replay it multiple times. Because the server validates only the API key and not the request context, the repeated operations execute as intended by the attacker. MiddleBrick’s checks for BOLA/IDOR and Unsafe Consumption include detecting missing replay protections where API keys are the primary credential.

In unauthenticated (black-box) scanning, middleBrick tests whether identical requests with the same API key produce the same outcome, which is indicative of a missing replay defense. The tool also inspects whether the API specification (OpenAPI/Swagger) documents replay safeguards such as x-idempotency-key or timestamp usage. Without these mechanisms, an API relying on static API keys remains vulnerable to replay even if the key itself is kept secret, because the trust boundary does not account for request duplication.

Additional exposure occurs if API keys are logged or exposed in referrer headers, error messages, or URLs, as this widens the attack surface. An intercepted log entry or browser referrer can give an attacker the necessary components to craft a replay request. middleBrick’s Data Exposure and Unsafe Consumption checks surface such risks by correlating runtime behavior with spec definitions, ensuring that the presence of API keys does not inadvertently aid replay.

It is important to note that middleBrick detects and reports these conditions but does not apply fixes. The scanner identifies whether replay protections like idempotency keys, timestamps, or one-time tokens are absent when API keys are used, providing prioritized findings with severity and remediation guidance to help teams address the issue.

To mitigate replay attacks in Actix when using API keys, you should introduce request uniqueness checks such as idempotency keys or timestamp nonces. Below are concrete, working examples that demonstrate how to implement these protections in an Actix web service.

First, include an idempotency key in the request headers and validate it server-side. This ensures that repeated requests with the same key and idempotency value are not processed more than once.

use actix_web::{web, App, HttpResponse, HttpServer, middleware::Logger};
use std::collections::HashSet;
use std::sync::{Arc, Mutex};

struct AppState {
    seen_idempotency_keys: Mutex>,
}

async fn transfer_funds(
    api_key: String,
    idempotency_key: web::Header<String>,
    body: web::Json<TransferRequest>,
    data: web::Data<Arc<AppState>>, // Assume proper validation of api_key
) -> HttpResponse {
    let mut seen = data.seen_idempotency_keys.lock().unwrap();
    let id = idempotency_key.into_inner();
    if !seen.insert(id.clone()) {
        return HttpResponse::Conflict().body("Idempotency key already used");
    }
    // Process transfer
    HttpResponse::Ok().body("Transfer completed")
}

#[derive(serde::Deserialize)]
struct TransferRequest {
    to: String,
    amount: u64,
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let app_state = web::Data::new(Arc::new(AppState {
        seen_idempotency_keys: Mutex::new(HashSet::new()),
    }));
    HttpServer::new(move || {
        App::new()
            .app_data(app_state.clone())
            .wrap(Logger::default())
            .route("/transfer", web::post().to(transfer_funds))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

Second, use a timestamp-based nonce to reject stale or duplicated requests within a short window. This approach requires clients to send a current timestamp and a signature derived from the payload, timestamp, and API key. The server verifies freshness and integrity before processing.

use actix_web::{web, App, HttpResponse, HttpServer, HttpRequest};
use std::time::{SystemTime, UNIX_EPOCH};

fn is_timestamp_fresh(req_ts: u64) -> bool {
    let now = SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .unwrap()
        .as_secs();
    now.saturating_sub(req_ts) <= 30 // 30-second window
}

async fn process_with_timestamp(
    api_key: String,
    req: HttpRequest,
    body: web::Bytes,
) -> HttpResponse {
    let timestamp = match req.headers().get("X-Timestamp") {
        Some(val) => val.to_str().unwrap_or("").parse<u64>(),
        None => return HttpResponse::BadRequest().body("Missing timestamp"),
    };
    let nonce = match req.headers().get("X-Nonce") {
        Some(val) => val.to_str().unwrap_or(""),
        None => return HttpResponse::BadRequest().body("Missing nonce"),
    };
    // In practice, validate signature using api_key, body, timestamp, nonce
    if timestamp.is_err() || !is_timestamp_fresh(timestamp.unwrap()) {
        return HttpResponse::Unauthorized().body("Stale or invalid timestamp");
    }
    // Proceed with request handling
    HttpResponse::Ok().body("Request accepted")
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .route("/secure", web::post().to(process_with_timestamp))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

These examples illustrate concrete steps you can take in Actix to reduce replay risk when API keys are in use. For a comprehensive view of how your API configuration and runtime behavior align with such protections, you can use the middleBrick CLI to scan from terminal with middlebrick scan <url>, or integrate the GitHub Action to add API security checks to your CI/CD pipeline and fail builds if risk scores exceed your threshold. The MCP Server also lets you scan APIs directly from your AI coding assistant within the development environment.