Race Condition in Actix with Hmac Signatures

A race condition in Actix when Hmac Signatures are used typically arises from timing differences in signature verification and state changes. If an endpoint both verifies an Hmac signature and modifies shared server-side state based on that request, an attacker can manipulate timing to observe inconsistent states between the signature check and the resulting operation.

Consider an Actix web service that uses Hmac Signatures to ensure request integrity and also performs inventory updates. The flow is: verify the Hmac, then decrement a stock count. An attacker can send many concurrent requests with valid signatures but crafted payloads that exploit the window between verification and state update. Because verification is fast and state change may involve I/O, an adversary can race to read or modify the resource after verification but before the update completes or rolls back.

This becomes a classic time-of-check-to-time-of-use (TOCTOU) problem. Even though the signature itself is valid, the application logic is not atomic: the signature proves authenticity of the message at one point, but does not guarantee that the resource state used in processing remains consistent through the entire handler execution. In distributed or multi-threaded Actix runtimes, multiple workers may interleave verification and state changes, amplifying the race window.

An example scenario: an endpoint /api/reserve uses Hmac Signatures to authenticate a reservation request. The handler verifies the Hmac, checks availability, and then reserves the item. If two identical requests with different nonces or timestamps arrive concurrently, both may pass signature verification and see available stock, leading to over-allocation. The race condition is not in the cryptographic verification itself, but in the lack of atomicity between verification and state mutation, made worse by Actix’s asynchronous, multi-threaded request handling.

From an API security scanner perspective, this pattern is flagged because the unauthenticated attack surface includes endpoints that perform state changes after signature validation without enforcing strict concurrency controls. The scanner tests whether timing and ordering assumptions can be exploited, for instance by sending rapid, slightly varied requests and inspecting side-effects or inconsistent responses.

To remediate race conditions with Hmac Signatures in Actix, ensure that verification and state-changing logic are executed atomically and avoid relying on timing-sensitive checks that can be gamed through concurrency.

First, use Actix’s extractor patterns to validate the Hmac signature early and then perform state changes within a single, coordinated critical section or transaction. Avoid yielding or awaiting between signature validation and state updates unless the underlying operation is already atomic or isolated.

Example 1: A safe handler that verifies Hmac and updates inventory within a single async block, without yielding to other tasks:

use actix_web::{post, web, HttpResponse, Result};
use hmac::{Hmac, Mac};
use sha2::Sha256;

type HmacSha256 = Hmac;

#[post("/api/reserve")]
async fn reserve_item(
    payload: web::Json,
    mac_header: actix_web::http::HeaderValue,
) -> Result {
    let secret = include_bytes!("./hmac_secret.key");
    let mut mac = HmacSha256::new_from_slice(secret)
        .map_err(|_| actix_web::error::ErrorInternalServerError("hmac init failed"))?;
    mac.update(&payload.body()); // body or selected canonical bytes
    // Verify signature before any state change
    let received_sig = mac_header.to_str().map_err(|_| actix_web::error::ErrorBadRequest("invalid header"))?;
    hex::decode(received_sig)
        .map_err(|_| actix_web::error::ErrorBadRequest("invalid signature encoding"))?
        .as_slice()
        .verify(&mac)
        .map_err(|_| actix_web::error::ErrorUnauthorized("invalid signature"))?;

    // Only after verification, perform state change — ideally within a DB transaction or mutex
    let mut conn = pool.get().await.map_err(|_| actix_web::error::ErrorInternalServerError("db error"))?;
    let tx = conn.transaction().await.map_err(|_| actix_web::error::ErrorInternalServerError("tx begin failed"))?;
    let available: i64 = sqlx::query_scalar("SELECT stock FROM items WHERE id = $1 FOR UPDATE")
        .bind(payload.item_id)
        .fetch_one(&mut *tx)
        .await?;
    if available < 1 {
        return Err(actix_web::error::ErrorConflict("insufficient stock"));
    }
    sqlx::query("UPDATE items SET stock = stock - 1 WHERE id = $1")
        .bind(payload.item_id)
        .execute(&mut *tx)
        .await?;
    tx.commit().await.map_err(|_| actix_web::error::ErrorInternalServerError("tx commit failed"))?;
    Ok(HttpResponse::Ok().finish())
}

The key points: the Hmac is verified first, then the handler opens a database transaction with SELECT … FOR UPDATE to lock the row, checks stock, and updates within the same transaction. This prevents other concurrent transactions from seeing an inconsistent state, effectively eliminating the race window.

Example 2: When a mutex is needed in-memory (for non-persistent coordination), wrap the critical region with Actix’s sync::Mutex:

use actix_web::{web, HttpResponse, Result};
use std::sync::Arc;
use tokio::sync::Mutex;

struct AppState {
    stock_mutex: Arc>>,
}

#[post("/api/reserve/{item_id}")]
async fn reserve_with_mutex(
    item_id: web::Path<i64>,
    state: web::Data<AppState>,
    payload: web::Json<ReservationPayload>,
    mac_header: actix_web::http::HeaderValue,
) -> Result {
    let secret = include_bytes!("./hmac_secret.key");
    let mut mac = HmacSha256::new_from_slice(secret)
        .map_err(|_| actix_web::error::ErrorInternalServerError("hmac init failed"))?;
    // Canonicalize payload for signing; here we use JSON bytes
    let payload_bytes = serde_json::to_vec(&*payload)?;
    mac.update(&payload_bytes);
    // Verify signature
    let received_sig = mac_header.to_str()?;
    hex::decode(received_sig)?
        .as_slice()
        .verify(&mac)
        .map_err(|_| actix_web::error::ErrorUnauthorized("invalid signature"))?;

    let mut guard = state.stock_mutex.lock().await;
    let stock = guard.entry(*item_id).or_insert(100);
    if *stock < 1 {
        return Err(actix_web::error::ErrorConflict("insufficient stock"));
    }
    *stock -= 1;
    // Mutex guard released here, after state is safely updated
    Ok(HttpResponse::Ok().finish())
}

In both examples, the Hmac signature is verified before the state change, and the state change is protected so that concurrent requests cannot interleave verification and mutation in a harmful way. This addresses the race condition while preserving the use of Hmac Signatures for request integrity.