Replay Attack in Gorilla Mux with Cockroachdb

A replay attack occurs when an attacker intercepts a valid request and retransmits it to reproduce an effect, such as transferring funds or changing state. When using Gorilla Mux as the router and CockroachDB as the backend store, the combination can inadvertently expose replay-vulnerable endpoints if idempotency and request uniqueness are not enforced at the application layer.

Gorilla Mux provides powerful URL routing and variable extraction but does not provide built-in replay protection. Developers must design handlers to ensure each request is unique. CockroachDB, a distributed SQL database, supports strong consistency and serializable isolation, which helps detect write conflicts, yet it does not prevent a replayed SQL statement from being applied again unless the application includes uniqueness constraints or idempotency keys.

Consider an endpoint that initiates a fund transfer via HTTP POST. If the request lacks a client-generated idempotency token (e.g., an idempotency-key header) and the server-side handler does not check for prior processing, an attacker can capture a valid request and replay it. With CockroachDB, the handler might insert a transaction that records the transfer without verifying whether that transaction has already been committed. Because CockroachDB uses serializable isolation, a replayed transaction that reuses the same business identifiers might result in a write conflict and retry; however, if the handler suppresses retries or uses upsert logic without uniqueness, the replay can succeed and cause duplicate operations.

Example risk pattern: a POST /transfer endpoint that accepts JSON body { "from": "A", "to": "B", "amount": 100 } without an idempotency key. An attacker replays the same JSON and headers. The handler starts a CockroachDB transaction, checks if a transfer record exists (perhaps by a composite key of from, to, and timestamp with low granularity), and if not, inserts a new record. Because the timestamp may have only second-level precision, or the check may rely on a non-unique constraint, the replayed transaction can pass the check and create a duplicate transfer.

Additionally, if the client uses authentication tokens that remain valid across requests and the transport lacks protections such as TLS with anti-replay mechanisms at the network level, captured requests can be replayed within the token’s validity window. The router’s context and middleware can pass user identity to handlers, but without explicit checks for request uniqueness in the database layer, replay remains possible.

To mitigate replay attacks in a Gorilla Mux and CockroachDB stack, enforce uniqueness at the database level and ensure idempotency at the handler level. Use a client-supplied idempotency key stored alongside a uniqueness constraint in CockroachDB, and make handlers transactional and idempotent.

First, define a table that includes a uniqueness constraint on the idempotency key. This ensures that any attempt to insert a duplicate key will violate the constraint, allowing the application to safely detect and reject replays.

-- CockroachDB schema for idempotent transfers
CREATE TABLE transfers (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    from_account STRING NOT NULL,
    to_account STRING NOT NULL,
    amount DECIMAL(12,2) NOT NULL,
    idempotency_key STRING UNIQUE NOT NULL,
    created_at TIMESTAMPTZ DEFAULT now()
);

Second, implement a handler in Go using Gorilla Mux that extracts the idempotency key from headers, begins a CockroachDB transaction, and attempts to insert the transfer only if the key is not already present. If the unique constraint violation occurs, the handler can safely return a success response (idempotent replay) without applying the operation again.

// Go handler example with Gorilla Mux and CockroachDB
func transferHandler(db *sql.DB) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        idempotencyKey := r.Header.Get("Idempotency-Key")
        if idempotencyKey == "" {
            http.Error(w, "Idempotency-Key header required", http.StatusBadRequest)
            return
        }

        from := r.FormValue("from")
        to := r.FormValue("to")
        amountStr := r.FormValue("amount")
        // validate inputs omitted for brevity

        tx, err := db.Begin()
        if err != nil {
            http.Error(w, "cannot start transaction", http.StatusInternalServerError)
            return
        }
        defer tx.Rollback()

        var existingID string
        err = tx.QueryRow("SELECT id FROM transfers WHERE idempotency_key = $1", idempotencyKey).Scan(&existingID)
        if err == nil {
            // Already processed: return success without re-applying business logic
            w.WriteHeader(http.StatusOK)
            w.Write([]byte(`{"status":"already_processed"}`))
            return
        }

        // Perform transfer
        _, err = tx.Exec(
            "INSERT INTO transfers (from_account, to_account, amount, idempotency_key) VALUES ($1, $2, $3, $4)",
            from, to, amountStr, idempotencyKey,
        )
        if err != nil {
            // Unique violation on idempotency_key could happen under race conditions
            if isUniqueViolation(err) {
                w.WriteHeader(http.StatusOK)
                w.Write([]byte(`{"status":"already_processed"}`))
                return
            }
            http.Error(w, "transfer failed", http.StatusInternalServerError)
            return
        }

        if err := tx.Commit(); err != nil {
            http.Error(w, "commit failed", http.StatusInternalServerError)
            return
        }

        w.WriteHeader(http.StatusOK)
        w.Write([]byte(`{"status":"ok"}`))
    }
}

Third, ensure that requests are transmitted over TLS to prevent on-path interception. While Gorilla Mux does not enforce transport security, you should configure your server with HTTPS. Combine this with short-lived, rotating authentication tokens to limit the window for replay. MiddleBrick scans can be used to verify that endpoints requiring idempotency include such protections and that TLS is enforced.

Finally, for high-safety operations, include a timestamp or nonce alongside the idempotency key and enforce server-side time windows (e.g., reject keys older than 24 hours). Store processed idempotency keys in CockroachDB with a TTL or periodic cleanup to avoid unbounded growth. This approach leverages CockroachDB’s strong consistency to make replayed transactions safely detectable and non-idempotent operations effectively idempotent.