Replay Attack in Axum with Cockroachdb

A replay attack occurs when an attacker intercepts a valid request and retransmits it to reproduce an authorized effect. In an Axum application using Cockroachdb as the backend, the risk typically arises from idempotency gaps around operations that mutate state, such as creating a resource or transferring funds. Cockroachdb, being a distributed SQL database, provides strong consistency for serializable transactions, but it does not automatically prevent a client from submitting the same request multiple times. If an endpoint does not include a deduplication mechanism—such as a unique client-generated idempotency key or a server-side transaction check—the same mutation can be applied more than once.

Consider an HTTP POST in Axum that inserts a payment record into a Cockroachdb table without checking for duplicates. An attacker who captures the request (e.g., via logs or network traces) can replay it with the same payload, causing a second row insertion or a double charge. In distributed deployments, Cockroachdb’s multi-region capabilities may introduce slight timing differences, but these do not inherently protect against replays. The vulnerability is not in Cockroachdb itself but in how the Axum service uses it: missing uniqueness constraints, missing idempotency tokens, or missing checks for prior execution allow the replay to succeed.

Another scenario involves authentication tokens or session cookies transmitted over insecure channels. If an Axum handler does not enforce strict transport security and a token is reused, an intercepted token can be replayed to gain unauthorized access. Cockroachdb’s role here is primarily as a reliable store for user sessions or credentials; if the token validation logic does not include a nonce or timestamp, replay remains possible. The combination of Axum’s routing and Cockroachdb’s storage can therefore expose replay risks when idempotency and freshness checks are absent.

To mitigate replay attacks in Axum with Cockroachdb, implement idempotency at both the application and database layers. Use unique constraints to ensure that duplicate operations are rejected safely, and validate freshness for authentication tokens. Below are concrete code examples for Axum handlers that interact with Cockroachdb using sqlx.

1. Idempotency key with a unique constraint

Create a table with a uniqueness guarantee on an idempotency key, and use an upsert pattern to ensure exactly-once execution. This leverages Cockroachdb’s serializable isolation to make the check-and-insert atomic.

-- Cockroachdb schema
CREATE TABLE payments (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    idempotency_key TEXT NOT NULL UNIQUE,
    user_id UUID NOT NULL,
    amount_cents INT NOT NULL,
    created_at TIMESTAMPTZ DEFAULT now()
);

// Axum handler using sqlx
use axum::{routing::post, Router, extract::State};
use serde::{Deserialize, Serialize};
use sqlx::postgres::PgPoolOptions;
use uuid::Uuid;

#[derive(Deserialize)]
struct CreatePaymentBody {
    idempotency_key: String,
    user_id: Uuid,
    amount_cents: i32,
}

#[derive(Serialize)]
struct PaymentResponse {
    id: Uuid,
}

async fn create_payment(
    State(pool): State<sqlx::PgPool>,
    body: axum::Json<CreatePaymentBody>,
) -> Result<axum::Json<PaymentResponse>, (axum::http::StatusCode, String)> {
    let pool = pool.clone();
    let key = &body.idempotency_key;
    let user_id = body.user_id;
    let amount = body.amount_cents;

    // Attempt to insert; if idempotency_key violates UNIQUE, fetch existing
    let result = sqlx::query!(
        r#"
        INSERT INTO payments (idempotency_key, user_id, amount_cents)
        VALUES ($1, $2, $3)
        ON CONFLICT (idempotency_key) DO NOTHING
        RETURNING id, created_at
        "#,
        key,
        user_id,
        amount
    )
    .fetch_optional(&pool)
    .await
    .map_err(|e| (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    match result {
        Some(row) => Ok(axum::Json(PaymentResponse { id: row.id })),
        None => {
            // Key already exists; ensure it’s the same request to avoid changing semantics
            let existing = sqlx::query!(
                r#"SELECT id, user_id, amount_cents, created_at FROM payments WHERE idempotency_key = $1"#,
                key
            )
            .fetch_one(&pool)
            .await
            .map_err(|e| (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

            // Optionally compare payload; if different, return conflict
            if existing.user_id != user_id || existing.amount_cents != amount {
                return Err((axum::http::StatusCode::CONFLICT, "Idempotency key used with different parameters".into()));
            }
            Ok(axum::Json(PaymentResponse { id: existing.id }))
        }
    }
}

#[tokio::main]
async fn main() {
    let pool = PgPoolOptions::new()
        .connect("postgresql://user:pass@host/db")
        .await
        .expect("failed to connect");

    let app = Router::new()
        .route("/payments", post(create_payment))
        .with_state(pool);

    axum::Server::bind(&("0.0.0.0:3000"))
        .serve(app.into_make_service())
        .await
        .unwrap();
}

2. Token replay protection with nonces and timestamps

For authentication or session endpoints, store a nonce (or use a timestamp window) in Cockroachdb and reject reused or stale requests.

-- Cockroachdb schema for nonces
CREATE TABLE auth_nonces (
    user_id UUID PRIMARY KEY,
    nonce TEXT NOT NULL,
    expires_at TIMESTAMPTZ NOT NULL
);

async fn verify_nonce(
    pool: &sqlx::PgPool,
    user_id: Uuid,
    nonce: &str,
    now: DateTime<Utc>,
) -> Result<(), (axum::http::StatusCode, String)> {
    // Enforce a time window (e.g., 5 minutes) to prevent replays
    let window_start = now - chrono::Duration::minutes(5);

    let existing: (String, DateTime) = sqlx::query_as(
        r#"SELECT nonce, expires_at FROM auth_nonces WHERE user_id = $1"#
    )
    .bind(user_id)
    .fetch_one(pool)
    .await
    .map_err(|e| (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    if existing.0 != nonce {
        return Err((axum::http::StatusCode::BAD_REQUEST, "Invalid or reused nonce".into()));
    }
    if existing.expires_at < window_start {
        return Err((axum::http::http::StatusCode::BAD_REQUEST, "Nonce expired".into()));
    }
    Ok(())
}

By combining a unique constraint on idempotency keys and strict nonce/timestamp validation, you reduce the surface for replay attacks across an Axum service backed by Cockroachdb. These patterns ensure that repeated requests either become no-ops (idempotency) or are rejected (freshness), without requiring changes to the database’s core consistency guarantees.