Insecure Design in Loopback with Cockroachdb

Insecure design in a Loopback application using CockroachDB often stems from trusting client-supplied data for routing, tenant isolation, or row-level access decisions. Because CockroachDB is a distributed SQL database that supports multi-tenant schemas and complex join patterns, a Loopback model that builds dynamic query filters from unvalidated input can unintentionally expose data across tenants or users. For example, if a controller uses req.query.userId to construct a where filter without verifying that the requesting user is authorized for that ID, an Insecure Direct Object Reference (IDOR) or Broken Object Level Authorization (BOLA) exists. This becomes more critical when schemas include organization or tenant columns, because an attacker can manipulate parameters to traverse records they should not access.

Another insecure pattern is over-permissive model scopes or relations in Loopback that expose nested associations without authorization checks. With CockroachDB, relationships that join across tenant-aware tables can return rows from other tenants if the join condition does not explicitly include tenant or ownership filters. For instance, defining a hasMany relation without a scoped where that enforces tenant ID allows any authenticated request to iterate related records via the API. Additionally, if the Loopback datasource is configured with broad credentials and the application relies solely on application-level filtering, an attacker who discovers the endpoint can use crafted query parameters or pagination to perform data enumeration or low-and-slow exfiltration.

Insecure design also appears in how the application handles access control lists (ACLs) and role-based permissions. If the Loopback model’s acls.json or static roles grant broad READ access on a model that backs sensitive CockroachDB tables, and the database rows are not filtered by user context, the API surface grows unnecessarily. Combined with CockroachDB’s support for secondary indexes and distributed scans, missing server-side authorization at the query layer means an attacker can leverage predictable IDs or enumeration patterns to map the dataset. The design flaw is not the database, but the decision to rely on client-supplied identifiers and weak model-level permissions rather than enforcing context-aware filters for every query.

Remediation focuses on ensuring every query emitted by Loopback includes tenant and ownership constraints and that authorization is validated before data is fetched. Instead of relying on model-level ACLs alone, enforce row-level security by always adding a where clause that includes the tenant ID derived from the authenticated context. Below is a secure Loopback model definition that scopes relations and queries to the current tenant.

// common/models/tenant-data.json
{
  "name": "tenantData",
  "base": "PersistedModel",
  "idInjection": true,
  "options": {
    "validateUpsert": true
  },
  "properties": {
    "tenantId": { "type": "string", "required": true },
    "sensitiveValue": { "type": "string", "required": true }
  },
  "acls": [
    { "principalType": "ROLE", "principalId": "$everyone", "permission": "DENY" },
    { "principalType": "ROLE", "principalId": "$authenticated", "permission": "ALLOW" }
  ],
  "relations": {
    "owner": {
      "type": "belongsTo",
      "model": "user",
      "foreignKey": "userId"
    }
  }
}

In your controller or a custom remote method, explicitly bind the tenant and user context to the query rather than accepting where fragments from the client:

// common/controllers/data.controller.js
module.exports = function (TenantData) {
  TenantData.findForCurrentUser = async function (userId, tenantId, options = {}) {
    if (!userId || !tenantId) {
      throw new Error('Missing context');
    }
    const whereClause = {
      and: [
        { tenantId: tenantId },
        { userId: userId }
      ]
    };
    return TenantData.find({ where: whereClause });
  };

  TenantData.remoteMethod(
    'findForCurrentUser', {
      accepts: [
        { arg: 'userId', type: 'string', required: true },
        { arg: 'tenantId', type: 'string', required: true },
        { arg: 'filter', type: 'object' }
      ],
      returns: { arg: 'data', type: ['TenantData'] },
      http: { path: '/for-current-user', verb: 'get' }
    }
    );
};

When defining model relations, avoid exposing unscoped associations. Instead, use a mixin or a base model that automatically injects tenant filters. For CockroachDB, this prevents cross-tenant index scans that could return rows belonging to other tenants when IDs collide across partitions.

// common/models/boot/tenant-scoping.js
module.exports = function (app) {
  const models = app.models;
  Object.keys(models).forEach(name => {
    const Model = models[name];
    if (Model.definition.settings && Model.definition.settings.tenantScoped !== false) {
      Model.observe('access', (ctx, next) => {
        const currentTenant = ctx.options && ctx.options.currentTenant;
        const currentUser = ctx.options && ctx.options.currentUser;
        if (currentTenant && currentUser) {
          if (!ctx.where) ctx.where = {};
          ctx.where.tenantId = currentTenant;
          ctx.where.userId = currentUser.id;
        }
        next();
      });
    }
  });
};

Finally, validate and normalize all incoming query inputs that affect filtering, sorting, or pagination. Do not allow client-supplied field names for ordering that could lead to information disclosure or performance issues on distributed execution plans in CockroachDB. Combine these practices with regular scans using middleBrick to detect regressions; for example, the CLI middlebrick scan <url> can be integrated into your workflow to highlight authorization and design weaknesses.