Distributed Denial Of Service in Express with Cockroachdb

When an Express application uses CockroachDB as its primary data store, certain patterns in request handling and database interaction can amplify availability risks. A distributed denial of service (DDoS) in this context is not always about volumetric traffic; it can also manifest as resource exhaustion at the application or database layer due to inefficient queries, missing limits, or unbounded operations.

Express does not provide built-in database-level concurrency controls, so if endpoints issue long-running or unbounded SQL queries against CockroachDB without timeouts or context cancellation, a single client can hold database connections and threads, reducing availability for others. CockroachDB, while horizontally scalable, still requires careful query design; unindexed lookups or large scans increase latency and consume node resources. In a high-concurrency scenario, many such requests can lead to connection pool saturation, increased latencies, and eventual request timeouts.

Another vector is missing rate limiting at the API layer. Without rate limiting, an attacker can flood endpoints that trigger heavy CockroachDB work (e.g., reporting endpoints with complex joins or aggregations). Since CockroachDB nodes coordinate across replicas, heavy distributed SQL queries can increase cross-node communication (range lookups and lease transfers), amplifying load across the cluster. If the Express app does not enforce request size limits or payload validation, large or malformed requests can also cause excessive parsing and validation overhead, tying up event loop and database resources.

Additionally, absent circuit breaker or retry logic with backoff in the data access layer, transient errors can cause clients to retry aggressively, multiplying load. CockroachDB returns specific error codes (e.g., unavailable SQL instances, range contention) that, if unhandled, can lead to retry storms from the Express app. Without idempotency keys or request deduplication, repeated POST or retry attempts can cause repeated writes or scans, further stressing the cluster. Proper instrumentation and query timeout handling in Express are essential to prevent the application from becoming an amplifier in a DDoS scenario involving CockroachDB.

Implement server-side mitigations in Express to reduce availability risks when interacting with CockroachDB. Use timeouts, context cancellation, query limits, and connection management to ensure the service remains responsive under load or abuse.

1. Query timeouts and context cancellation

Always use timeouts and request-scoped contexts to prevent long-running queries from tying up resources. This ensures that a single slow query does not block the event loop or exhaust connection pools.

const { Pool } = require('pg');
const express = require('express');
const app = express();

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  // pgbouncer or similar connection pooler in front of CockroachDB
});

app.get('/users/:id', async (req, res, next) => {
  const client = await pool.connect();
  try {
    const timeoutMs = 3000;
    const queryStart = Date.now();
    const result = await client.query(
      'SELECT id, name, email FROM users WHERE id = $1 AND created_at > NOW() - INTERVAL \'90 days\'',
      [req.params.id],
      { statement_timeout: timeoutMs }
    );
    res.json(result.rows);
  } catch (err) {
    next(err);
  } finally {
    client.release();
  }
});

app.use((err, req, res, next) => {
  if (err && err.code === '57014') {
    res.status(408).json({ error: 'Request timeout' });
  } else {
    res.status(500).json({ error: 'Internal server error' });
  }
});

app.listen(3000);

2. Parameterized queries and index usage

Use parameterized queries to avoid plan cache bloat and ensure CockroachDB can reuse execution plans. Ensure WHERE clauses reference indexed columns to avoid full table scans that consume I/O and memory.

// Good: indexed lookup with prepared statement style via parameterization
app.get('/reports', async (req, res, next) => {
  const { start, end, limit = '100' } = req.query;
  const client = await pool.connect();
  try {
    // Validate and coerce limit to integer to avoid injection via parseing
    const limitInt = Math.min(parseInt(limit, 10) || 100, 1000);
    const result = await client.query(
      'SELECT date, count FROM events WHERE org_id = $1 AND event_time BETWEEN $2 AND $3 ORDER BY event_time DESC LIMIT $4',
      [req.tenantId, start, end, limitInt]
    );
    res.json(result.rows);
  } catch (err) {
    next(err);
  } finally {
    client.release();
  }
});

3. Rate limiting and request validation

Apply per-route rate limits to protect expensive endpoints. Validate payloads early to avoid unnecessary parsing and SQL planning work.

const rateLimit = require('express-rate-limit');

const apiLimiter = rateLimit({
  windowMs: 60 * 1000,
  max: 100,
  standardHeaders: true,
  legacyHeaders: false,
  message: { error: 'Too many requests' },
});

app.use('/api/reports', apiLimiter);
app.post('/api/events', express.json({ limit: '1mb' }), (req, res) => {
  // Validate required fields before DB interaction
  if (!req.body.orgId || !req.body.events || !Array.isArray(req.body.events)) {
    return res.status(400).json({ error: 'Invalid payload' });
  }
  // proceed with batched insert or upsert
  res.status(202).json({ accepted: true });
});

4. Graceful error handling and retries with backoff

Handle CockroachDB-specific errors (e.g., unavailable nodes, range contention) with exponential backoff to avoid retry storms. Use an idempotency key for mutating requests where applicable.

const retry = require('async-retry');

app.post('/orders', async (req, res, next) => {
  const idempotencyKey = req.get('Idempotency-Key');
  await retry(
    async (bail) => {
      const client = await pool.connect();
      try {
        const result = await client.query(
          'INSERT INTO orders (id, user_id, total) VALUES ($1, $2, $3) ON CONFLICT DO NOTHING',
          [idempotencyKey, req.body.userId, req.body.total],
          { statement_timeout: 5000 }
        );
        res.status(201).json({ success: true });
      } catch (err) {
        if (err.code === '53300') {
          // too many concurrent requests, don't retry
          bail(err);
        } else {
          throw err;
        }
      } finally {
        client.release();
      }
    },
    { retries: 3, minTimeout: 50, factor: 2 }
  ).catch(next);
});