Denial Of Service in Express with Cockroachdb

When an Express application uses CockroachDB as its primary data store, certain patterns in request handling, query construction, and connection management can amplify availability risks. A DoS scenario often arises when unbounded or poorly constrained SQL queries are triggered by user input, leading to heavy contention, long-running transactions, or excessive memory usage on the database nodes.

In a distributed SQL database like CockroachDB, long-running or poorly optimized queries can consume significant compute and storage resources across multiple nodes. If an endpoint executes a complex join or a full-table scan without proper indexes, the database may experience increased latency or backpressure. Under sustained load, this can manifest as timeouts or thread starvation in the application layer, causing service disruption even when the database itself remains responsive.

Another vector specific to this stack is connection pool exhaustion. If an Express app opens many unmanaged database connections or fails to release them properly during error conditions, the available connections can be exhausted. CockroachDB enforces limits on concurrent connections and transaction contention; when those limits are approached, new requests may be delayed or rejected. This is particularly relevant when requests perform multiple sequential queries within a single transaction or when session handling is misconfigured.

Input validation deficiencies also play a role. Without strict validation, an attacker may craft requests that generate expensive queries, such as searches with wide-range filters or deeply nested pagination. CockroachDB’s query planner must optimize these queries, which can lead to high CPU utilization across nodes. Combine this with an unthrottled request rate, and the system may degrade for all users, illustrating a classic application-layer DoS amplified by database behavior.

Finally, improper error handling can turn transient issues into availability problems. If an Express route does not handle CockroachDB-specific errors such as transaction retries or contention errors gracefully, clients may retry aggressively, increasing load. Effective DoS mitigation in this stack requires coordinated attention to query design, resource limits, and runtime behavior rather than relying solely than infrastructure-level protections.

Defensive coding patterns and explicit resource controls are essential when Express interacts with CockroachDB. The following examples demonstrate how to reduce availability risk through parameterized queries, timeouts, context cancellation, and proper transaction handling.

First, always use parameterized queries to prevent resource-intensive ad-hoc query plans and to protect against injection that could trigger expensive operations:

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

const client = new Client({
  connectionString: process.env.DATABASE_URL,
  application_name: 'api-service',
  keepAliveInitialDelayMillis: 30000,
});

await client.connect();

app.get('/users/:orgId', async (req, res, next) => {
  const { orgId } = req.params;
  // Validate input strictly before using in query
  if (!/^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i.test(orgId)) {
    return res.status(400).json({ error: 'invalid orgId' });
  }

  const queryConfig = {
    text: 'SELECT id, name, email FROM users WHERE org_id = $1 AND status = $2',
    values: [orgId, 'active'],
    timeout: 15000,
  };

  try {
    const result = await client.query(queryConfig);
    res.json(result.rows);
  } catch (err) {
    next(err);
  }
});

This pattern constrains query behavior, enforces input validation, and sets a statement timeout to prevent runaway queries from consuming resources indefinitely.

Second, manage transactions carefully with explicit rollback on errors and bounded retry strategies to avoid amplifying contention:

async function updateUserWithRetry(client, userId, data, maxAttempts = 3) {
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    const transaction = client.transaction();
    try {
      await transaction.query('BEGIN');
      const res = await transaction.query(
        'UPDATE users SET email = $1, updated_at = now() WHERE id = $2',
        [data.email, userId]
      );
      await transaction.query('COMMIT');
      return res;
    } catch (err) {
      await transaction.query('ROLLBACK');
      if (err.code === '40001' && attempt < maxAttempts) {
        // Serialization failure; wait and retry
        await new Promise((r) => setTimeout(r, 50 * attempt));
        continue;
      }
      throw err;
    }
  }
  throw new Error('Transaction failed after retries');
}

Third, enforce request-scoped timeouts and context propagation to ensure that slow or stuck queries do not tie up event-loop resources:

const { setTimeout } = require('node:timers/promises');

app.get('/reports/:reportId', async (req, res, next) => {
  const { reportId } = req.params;
  const controller = new AbortController();
  const timeoutId = setTimeout(() => controller.abort(), 12000);

  try {
    const result = await client.query({
      text: 'SELECT report_data FROM reports WHERE id = $1',
      values: [reportId],
      signal: controller.signal,
    });
    clearTimeout(timeoutId);
    res.json(result.rows[0]);
  } catch (err) {
    clearTimeout(timeoutId);
    if (err.name === 'AbortError') {
      return res.status(504).json({ error: 'upstream timeout' });
    }
    next(err);
  }
});

Additionally, configure connection pool limits to align with CockroachDB’s capacity characteristics. Avoid unbounded pools in favor of controlled concurrency:

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  max: 20,
  acquireTimeoutMillis: 5000,
  idleTimeoutMillis: 30000,
});

Finally, monitor query patterns and leverage CockroachDB’s built-ins such as EXPLAIN to validate that indexes are used. Remediation is complete when queries are bounded, transactions are short, and the application fails predictably under pressure rather than cascading into broader outages.