Replay Attack in Fiber with Cockroachdb

A replay attack occurs when an attacker intercepts a valid request and retransmits it to reproduce its effect. In a Fiber application using Cockroachdb as the backend, this risk is shaped by how the API manages idempotency and timestamps rather than by Cockroachdb itself being the direct cause.

Without unique request identifiers or strict server-side checks, an HTTP POST that creates a resource (for example, transferring funds or recording an order) can be captured and replayed. Because Cockroachdb provides strong consistency and serializable isolation, a replayed request may still succeed at the database level, applying the same write again if the application does not prevent it. This is especially relevant for endpoints that rely on simple incrementing counters or timestamps that do not change between replays.

Consider an endpoint that creates a payment record using a client-supplied request_id. If the server does not enforce uniqueness on request_id in Cockroachdb, an attacker can replay the same request with the same ID and cause duplicate entries or double-spending. Even when using unique identifiers, if the server only checks that a record does not exist and performs a separate insert, a race condition can allow concurrent replays to pass the existence check before any insert completes, due to transaction isolation nuances in distributed SQL execution.

Insecure transport compounds the issue. Without TLS, requests can be observed and replayed even when Cockroachdb enforces strong consistency. Additionally, endpoints that use predictable paths or parameters (e.g., sequential IDs) can be targeted for replay without needing deep insight into the database schema. The interaction between Fiber’s lightweight routing and Cockroachdb’s distributed transactions means that developers must explicitly design for idempotency, because the database will faithfully execute repeated statements rather than reject them as duplicates.

To detect this class of issue, scanners perform black-box testing by sending repeated requests with the same parameters and inspecting whether the application enforces uniqueness or includes protections such as one-time tokens. They also check whether TLS is enforced and whether request identifiers are validated server-side against Cockroachdb in a manner that prevents duplicate processing.

Remediation centers on making every write operation idempotent and verifiable. The recommended approach is to use a unique constraint on a client-supplied idempotency key and handle violations explicitly. This ensures that a replayed request fails gracefully instead of creating duplicate side effects.

First, define a table with a uniqueness constraint on the idempotency key. The following Cockroachdb SQL creates a payments table where idempotency_key must be unique:

CREATE TABLE payments (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL,
    amount DECIMAL(10, 2) NOT NULL,
    idempotency_key TEXT NOT NULL,
    created_at TIMESTAMPTZ DEFAULT now(),
    CONSTRAINT unique_idempotency UNIQUE (idempotency_key)
);

In your Fiber handler, compute a stable key from the request body or headers and attempt to insert. If a uniqueness violation occurs, treat it as a duplicate and return the original response rather than processing again:

const { Pool } = require('pg');
const { v4: uuidv4 } = require('uuid');

const pool = new Pool({
  connectionString: process.env.COCKROACHDB_URL,
  ssl: {
    rejectUnauthorized: false // Use proper CA in production
  }
});

async function createPayment(req, res) {
  const client = await pool.connect();
  try {
    const idempotencyKey = req.headers['idempotency-key'] || uuidv4();
    const { amount, user_id } = req.body;

    const query = `
      INSERT INTO payments (user_id, amount, idempotency_key)
      VALUES ($1, $2, $3)
      ON CONFLICT (idempotency_key) DO NOTHING
      RETURNING id, created_at
    `;
    const result = await client.query(query, [user_id, amount, idempotencyKey]);

    if (result.rows.length === 0) {
      // Duplicate request: fetch the original record by key if you store it
      const lookup = await client.query(
        'SELECT id, created_at FROM payments WHERE idempotency_key = $1',
        [idempotencyKey]
      );
      return res.status(200).json(lookup.rows[0]);
    }

    res.status(201).json(result.rows[0]);
  } catch (err) {
    console.error(err);
    res.status(500).json({ error: 'Internal server error' });
  } finally {
    client.release();
  }
}

app.post('/payments', createPayment);

This pattern relies on Cockroachdb’s ON CONFLICT DO NOTHING to enforce idempotency at the database level, avoiding race conditions between a check-then-insert sequence. For endpoints that require returning the original response, store an opaque response snapshot (e.g., response body or a generated token) alongside the key and return it on conflict.

Additionally, enforce TLS in production and require idempotency keys for any non-GET operation. Monitor for repeated conflict rates as an indicator of potential replay attempts. MiddleBrick scans can validate that such uniqueness constraints exist and that endpoints verify server-side state rather than relying solely on client-supplied metadata.