Ssrf in Express with Cockroachdb

Server-Side Request Forgery (SSRF) in an Express application that interacts with CockroachDB can occur when user-supplied input is used to construct URLs for database drivers or HTTP requests without proper validation. CockroachDB, while PostgreSQL-wire compatible, exposes a SQL interface; if an attacker can influence a URL that the server later uses to connect to an external service (for example, during a foreign data wrapper request, an HTTP-based backup endpoint, or a webhook), they may force the server to reach internal resources or bypass network ACLs. In an Express context, this often manifests in code that builds a connection string or an HTTP request based on parameters such as host, port, or database provided by the client. Because the scan tests unauthenticated attack surfaces, middleBrick can detect SSRF indicators when it observes dynamic URL construction feeding into network calls without validation, even when the backend database is CockroachDB.

Consider an Express route that accepts a host and port to report a status to an arbitrary endpoint:

app.get('/report', (req, res) => {
  const { host, port } = req.query;
  const url = `http://${host}:${port}/status`;
  fetch(url).then(r => r.text()).then(console.log);
  res.send('ok');
});

If this endpoint is used by a CockroachDB-driven service to register or update its reachability, an attacker can supply an internal address such as localhost:26257 (CockroachDB’s default port) or metadata service IPs, leading to internal probing or data exposure. Even when CockroachDB is not directly involved in the HTTP call, patterns such as dynamic Data Source Names (DSNs) built from user input can similarly expose SSRF when the application later uses that DSN to open a database connection. The scanner’s checks for SSRF therefore focus on identifying whether network destinations are derived from untrusted input and whether appropriate allowlists or egress controls are in place.

In a typical scan, middleBrick follows the 12 checks in parallel. For SSRF, it looks for indicators such as dynamic URL assembly, missing validation of host or protocol, and absence of network egress restrictions. Because the scan is unauthenticated, it does not need credentials to identify these risky patterns in the API surface exposed by Express routes. The findings include severity, context, and remediation guidance, enabling developers to understand how an SSRF chain might be chained with other weaknesses to reach CockroachDB administrative interfaces or internal services.

Remediation centers on strict input validation, allowlisting, and avoiding dynamic URL construction from client data. For Express routes that interact with CockroachDB, use parameterized queries instead of string interpolation, and never forward raw user input to network destinations. Below are concrete, realistic code examples demonstrating secure patterns.

1. Validate and restrict network targets

Do not use user input directly in URLs. If you must perform outbound calls, validate against an allowlist of known hosts and ports. For example:

const ALLOWED_HOSTS = new Set(['status.example.com', 'health.example.com']);

app.get('/report', (req, res) => {
  const host = req.query.host;
  const port = Number(req.query.port);
  if (!ALLOWED_HOSTS.has(host) || ![80, 443, 8080].includes(port)) {
    return res.status(400).send('invalid target');
  }
  const url = `http://${host}:${port}/status`;
  fetch(url).then(r => r.text()).then(console.log).catch(console.error);
  res.send('ok');
});

This ensures that even if an attacker controls host and port, they cannot reach internal CockroachDB listeners or sensitive internal services.

2. Use parameterized queries for CockroachDB

When querying CockroachDB from Express, always use parameterized statements to avoid SQL injection and prevent accidental data leakage. Do not construct SQL from concatenated strings based on user input.

const { Pool } = require('pg');
const pool = new Pool({ connectionString: process.env.DATABASE_URL });

app.get('/user', async (req, res) => {
  const userId = req.query.userId;
  try {
    const result = await pool.query('SELECT id, name FROM users WHERE id = $1', [userId]);
    res.json(result.rows);
  } catch (err) {
    console.error(err);
    res.status(500).send('server error');
  }
});

This approach isolates SQL logic from transport and ensures that user input cannot alter query structure or expose internal database details through error messages.

3. Secure outbound database and HTTP configurations

If your Express service uses CockroachDB as a backend and also makes outbound calls, enforce network-level controls. For example, configure your container or host firewall to restrict egress to known endpoints only. In code, avoid passing raw configuration to drivers:

// Avoid this: building DSN from user input
const userHost = req.query.host;
const dsn = `postgresql://${userHost}:26257/mydb`;
const client = new Pool({ connectionString: dsn }); // Risky

// Prefer: use a fixed, configured connection string
const pool = new Pool({ connectionString: process.env.DATABASE_URL });

By keeping DSNs static and sourced from environment variables, you reduce the attack surface for SSRF and prevent runtime manipulation of database endpoints. middleBrick’s scans will flag dynamic DSN construction and missing egress controls as high-severity findings, and the remediation guidance will point to these exact patterns.