Broken Access Control in Feathersjs with Cockroachdb

Broken Access Control occurs when an API fails to enforce proper authorization checks, allowing one user to access or modify another user's resources. In Feathersjs with Cockroachdb, this risk is heightened when service logic or hooks do not scope database queries to the authenticated subject. Feathersjs is service-oriented and relies on hooks for cross-cutting concerns such as authentication and authorization; if these hooks are missing or misconfigured, the application may pass an unverified user identity into Cockroachdb queries.

Consider a typical Feathersjs service for user profiles that uses an ORM or query builder to communicate with Cockroachdb. If the service does not explicitly filter by user ID, an attacker can manipulate request parameters to access or update other users' records. For example, a GET /users/:id endpoint might extract :id from the request without confirming that the authenticated user owns that ID. Because Cockroachdb enforces SQL semantics strictly, an unchecked identifier is passed directly into the query, enabling horizontal privilege escalation across rows that belong to other users.

Common root causes include missing ownership checks in before hooks, overly permissive "everyone" or "anonymous" hooks, and improper use of $or / $and in query conditions. Attack patterns such as Insecure Direct Object References (IDOR) and Broken Object Level Authorization (BOLA) map directly to this issue. The unauthenticated attack surface tested by middleBrick can expose these flaws when service definitions lack scoped authorization and when Cockroachdb queries are constructed from user-supplied input without strict validation.

middleBrick scans such endpoints and flags findings like missing ownership validation, excessive permissions in service hooks, and unsafe query construction. The scanner reports these as high-severity Broken Access Control findings, providing prioritized remediation guidance aligned with OWASP API Top 10 and compliance frameworks. Note that middleBrick detects and reports these issues; it does not modify code or block execution.

To remediate Broken Access Control in Feathersjs with Cockroachdb, enforce user ownership at the query layer and in hooks. Always scope SELECT, UPDATE, and DELETE operations to the authenticated subject's ID, and validate that the requesting user matches the resource owner before constructing SQL conditions.

Example: A users service that safely scopes queries to the authenticated user using Sequelize-style syntax (or compatible query builder) with Cockroachdb:

// services/users/users.class.js
const { Service } = require('feathersjs');

class UserService extends Service {
  async find(params) {
    // Ensure the query is scoped to the authenticated user
    const { user } = params;
    if (user && user.id) {
      // Override the query to restrict by owner
      params.query = {
        ...params.query,
        where: {
          id: user.id
        }
      };
    }
    return super.find(params);
  }

  async get(id, params) {
    const { user } = params;
    if (!user || user.id !== id) {
      throw new Error('Not found');
    }
    return super.get(id, params);
  }
}

module.exports = function (app) {
  const options = { name: 'users', Model: app.get('knex') /* or your Cockroachdb client */ };
  app.use('/users', new UserService(options));
};

Example: A posts service with before hooks that enforce ownership on update and patch operations:

// services/posts/posts.hooks.js
const { iff, isProvider } = require('feathersjs-hooks-common');
const { authenticate } = require('feathersjs-authentication').hooks;
const { restrictToOwner } = require('feathersjs-hooks-common');

module.exports = {
  before: {
    all: [
      authenticate('jwt')
    ],
    find: [
      // Scopes the query to the authenticated user's ID
      restrictToOwner({ id: 'user._id', ownerField: 'userId', queryField: 'where.userId' })
    ],
    get: [
      restrictToOwner({ id: 'user._id', ownerField: 'userId', queryField: 'where.userId' })
    ],
    create: [
      // Attach the user ID to the data before insert
      async context => {
        context.data.userId = context.params.user._id;
        return context;
      }
    ],
    update: [
      restrictToOwner({ id: 'user._id', ownerField: 'userId', queryField: 'where.userId' })
    ],
    patch: [
      restrictToOwner({ id: 'user._id', ownerField: 'userId', queryField: 'where.userId' })
    ],
    remove: [
      restrictToOwner({ id: 'user._id', ownerField: 'userId', queryField: 'where.userId' })
    ]
  },

  after: {
    all: [],
    find: [],
    get: [],
    create: [],
    update: [],
    patch: [],
    remove: []
  },

  error: {
    all: [],
    find: [],
    get: [],
    create: [],
    update: [],
    patch: [],
    remove: []
  }
};

When using raw Cockroachdb queries (e.g., with node-postgres), construct parameterized queries that include the user ID explicitly and avoid string interpolation:

// db client example with parameterized query
const pool = require('cockroachdb')('your-connection-string');

async function getUserById(userId, requestingUserId) {
  if (userId !== requestingUserId) {
    throw new Error('Unauthorized');
  }
  const result = await pool.query('SELECT id, email, name FROM users WHERE id = $1 AND id = $1', [userId]);
  return result.rows[0];
}

These patterns ensure that every Cockroachdb interaction respects ownership, reducing the risk of IDOR and BOLA vulnerabilities. middleBrick can validate that such scoping exists by scanning endpoints and inspecting hooks and query construction.