Privilege Escalation in Express with Cockroachdb

Privilege escalation in an Express API that uses CockroachDB often stems from authorization checks being performed at the application layer without strict alignment to database-level permissions and row-level constraints. When endpoints rely on user-supplied identifiers (e.g., :userId, :resourceId) and construct SQL dynamically or via ORM without validating that the requesting user is permitted to act on that specific resource, attackers can manipulate parameters to access or modify data belonging to other users.

With CockroachDB, which provides strong SQL semantics and role-based access control, the risk arises when Express routes do not enforce ownership or tenant context per request. For example, an endpoint like GET /users/:userId might issue a query such as SELECT * FROM users WHERE id = $1 using a parameter directly from the request. If the route does not verify that the authenticated user matches :userId or that the user’s role permits broader access, an attacker can change :userId to another valid user ID and read or infer sensitive data. This is a classic BOLA/IDOR pattern, and it is especially dangerous when combined with overly permissive database roles granted to the application user.

CockroachDB’s native support for row-level security (RLS) can mitigate this, but if Express does not leverage RLS or uses a shared application-level user identity for all queries, the protection gap remains. Consider a query built with string concatenation or naive parameter binding that includes tenant or organization context only at the application layer. An attacker who can modify numeric IDs may traverse across tenant boundaries if the query does not enforce tenant_id = current_tenant_id in both the application logic and the database policy. Insecure default configurations in CockroachDB, such as granting the app user broader privileges than necessary, further widen the impact of such authorization flaws.

The LLM/AI Security checks available in middleBrick are particularly valuable here because they can detect system prompt leakage and test for jailbreak-style manipulations that might coax the API to reveal higher-privilege behaviors or data patterns. These probes can surface indirect paths where improper authorization in Express combined with CockroachDB permissions allows unintended operations, such as modifying other users’ records or escalating role claims.

To reduce risk, align Express middleware authorization with CockroachDB roles and policies: use verified context from authentication, enforce tenant and ownership filters in every query, and apply least-privilege database permissions. Complement this with active scanning that validates whether tampered IDs or manipulated tokens expose privilege escalation paths, ensuring that both application logic and database configuration work together to contain access.

Secure Express routes that interact with CockroachDB by validating ownership, using parameterized queries, and enforcing role-based access at both the application and database levels. The following examples demonstrate concrete fixes for common privilege escalation scenarios.

First, ensure your CockroachDB user for Express has the minimum necessary privileges. Avoid granting blanket admin rights; instead, define roles that align with the operations your API performs. For example:

-- Example CockroachDB role setup (run once in your cluster)
CREATE ROLE express_app;
GRANT SELECT, INSERT, UPDATE ON TABLE users TO express_app;
-- Restrict updates to only rows where the user matches the requesting identity
-- Use application-enforced filters in tandem; RLS can add defense-in-depth
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
CREATE POLICY users_own_data ON users FOR UPDATE USING (id = $1);

In Express, use middleware to resolve the current user and enforce tenant context before building queries. Always bind parameters rather than interpolating values:

const express = require('express');
const { Pool } = require('pg'); // CockroachDB wire-compatible
const app = express();
app.use(express.json());

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

// Middleware to attach user context (from auth, e.g., JWT)
app.use((req, res, next) => {
  req.user = { id: 'usr_123', role: 'standard', tenantId: 'org_abc' }; // resolved securely
  next();
});

// Secure GET /users/me that avoids ID manipulation
app.get('/users/me', async (req, res) => {
  const client = await pool.connect();
  try {
    const result = await client.query(
      'SELECT id, email, profile FROM users WHERE id = $1 AND tenant_id = $2',
      [req.user.id, req.user.tenantId]
    );
    if (result.rows.length === 0) {
      return res.status(404).json({ error: 'Not found' });
    }
    res.json(result.rows[0]);
  } finally {
    client.release();
  }
});

// Secure PUT /users/:id with ownership check
app.put('/users/:id', async (req, res) => {
  const client = await pool.connect();
  try {
    const result = await client.query(
      'UPDATE users SET email = $1 WHERE id = $2 AND tenant_id = $3 AND id = $4 RETURNING id',
      [req.body.email, req.user.id, req.user.tenantId, req.params.id]
    );
    if (result.rowCount === 0) {
      return res.status(403).json({ error: 'Forbidden or not found' });
    }
    res.json(result.rows[0]);
  } finally {
    client.release();
  }
});

For endpoints that must act on other resources, repeat ownership verification using CockroachDB-side checks where possible and avoid dynamic SQL that concatenates identifiers. When using an ORM, ensure it does not strip tenant filters or allow unsafe includes.

middleBrick’s CLI can be used to validate that your endpoints do not expose privilege escalation paths by submitting your API URL and reviewing the BOLA/IDOR and Privilege Escalation findings. The CLI outputs structured results you can integrate into scripts, while the Pro plan’s continuous monitoring can alert you if a new endpoint introduces insecure parameter handling. If you integrate middleBrick into your development workflow via the GitHub Action, you can fail builds when risk scores exceed your defined thresholds, and the MCP Server lets you scan APIs directly from AI coding assistants within your IDE.