Bola Idor in Feathersjs with Hmac Signatures

BOLA (Broken Level of Authorization) / IDOR occurs when an API allows one user to access or modify another user's resources despite authorization checks. In FeathersJS, this risk can manifest when HMAC signatures are used to authenticate requests but the endpoint logic does not enforce ownership or tenant boundaries. FeathersJS is a flexible framework that lets you define services with custom logic; if the service handler only validates the HMAC signature and does not also verify that the resource being accessed (e.g., a user profile, a record, or a file) belongs to the authenticated principal, BOLA/IDOR arises.

Consider a Feathers service for user settings. A client signs a request with an HMAC derived from a shared secret and the payload. The server verifies the signature to ensure integrity and origin, but then directly uses an incoming userId parameter to look up the settings record without confirming that the authenticated principal is that same user. Because the signature validated, the framework processes the request as authorized, yet the operation is acting on another user’s data if the userId is tampered with. This is a classic IDOR: authorization is bypassed because the business logic skipped an ownership check.

HMAC signatures protect integrity and non-repudiation, but they do not enforce authorization boundaries. In FeathersJS, this gap often appears when developers rely solely on authentication middleware (e.g., a custom HMAC hook) and then perform data access using untrusted client-supplied identifiers (like id or userId) without scoping the query to the authenticated subject. For example, a GET /records/:id endpoint might validate HMAC and then do app.service('records').get(params.id) without ensuring the record’s owner matches the authenticated entity. An attacker who knows or guesses another record ID can thus read or modify data across privilege boundaries, despite valid HMAC authentication.

Additionally, mass assignment or unsafe consumption can amplify BOLA when combined with HMAC. If a PATCH request signed with HMAC allows the client to supply an ownerId field and the server applies the update without confirming that the authenticated principal matches that ownerId, the attacker can change ownership of resources. Even with a strong HMAC scheme, the server must scope queries to the authenticated principal’s scope (e.g., by injecting the principal ID into the query filters) and validate that the target resource’s owner matches that principal before any read, update, or delete operation.

To remediate BOLA/IDOR when using HMAC signatures in FeathersJS, you must couple signature validation with strict ownership scoping and avoid trusting client-supplied identifiers for access control decisions. Below are concrete patterns and code examples to implement this correctly.

1. Validate HMAC and scope queries to the authenticated principal

After verifying the HMAC, ensure that data access is constrained to the authenticated principal. Do not rely on the client-provided ID alone; instead, inject the principal into the query filters.

// Example: Feathers before hook for HMAC validation + ownership scoping
const crypto = require('crypto');

function verifyHmacAndScope(secret) {
  return async context => {
    const { headers, method, url, body } = context.params.raw || {};
    const receivedSignature = headers['x-hmac-signature'];
    const payload = JSON.stringify(body || {});
    const expected = crypto.createHmac('sha256', secret).update(payload).digest('hex');

    if (!receivedSignature || receivedSignature !== expected) {
      throw new Error('Invalid HMAC');
    }

    // Assume the principal identity is resolved elsewhere (e.g., from a token or cert)
    // and attached to context.principal.userId
    if (!context.principal || !context.principal.userId) {
      throw new Error('Unauthenticated');
    }

    // Scope the query to the authenticated principal
    if (context.params.query) {
      context.params.query.userId = context.principal.userId;
    } else {
      context.params.query = { userId: context.principal.userId };
    }

    return context;
  };
}

// Usage in a Feathers service
const authentication = require('feathers-authentication');
const hooks = require('feathers-hooks-common');

app.service('settings').hooks({
  before: {
    all: [
      authentication.hooks.authenticate(['hmac']),
      verifyHmacAndScope('your-hmac-secret')
    ],
    find: [hooks.ensureOwner({ idField: 'userId', ownerField: 'userId' })],
    get: [hooks.ensureOwner({ idField: 'id', ownerField: 'userId' })],
    update: [hooks.ensureOwner({ idField: 'id', ownerField: 'userId' })],
    patch: [hooks.ensureOwner({ idField: 'id', ownerField: 'userId' })],
    remove: [hooks.ensureOwner({ idField: 'id', ownerField: 'userId' })]
  }
});

2. Avoid trusting client-supplied identifiers for sensitive operations

When updating or deleting a record, do not allow the client to dictate the target ID without scoping. Instead, derive the ID from the authenticated principal or from a trusted source, and use that to locate the resource.

// Example: Safe PATCH handler that ignores client-supplied ID for ownership
app.service('documents').hooks({
  before: {
    patch: [async context => {
      // Verify HMAC as shown earlier
      // ...

      // Force the ID to be the authenticated principal's document
      const userId = context.principal.userId;
      const recordId = context.id; // ID from URL path, still validated for existence

      // Fetch the existing record to confirm ownership
      const record = await app.service('documents').get(recordId);
      if (!record || record.userId !== userId) {
        throw new Error('Forbidden: you do not own this document');
      }

      // Apply patch data, but do not allow changing ownership
      if (context.data.userId && context.data.userId !== userId) {
        delete context.data.userId;
      }

      return context;
    }]
  }
});

3. Use framework hooks and common patterns to enforce ownership

Leverage feathers-hooks-common patterns such as ensureOwner or build a custom hook that scopes every query to the authenticated principal. This ensures that even if a client sends an explicit ID, the backend filters by the principal’s scope before executing the database operation.

// Custom hook to enforce ownership across CRUD
function ensureOwner({ idField = 'id', ownerField = 'userId' }) {
  return async context => {
    const ownerId = context.principal && context.principal[ownerField];
    if (!ownerId) {
      throw new Error('Unauthorized');
    }

    // For get/remove, ensure the target ID matches the owner
    if (context.id !== undefined) {
      const record = await context.app.service(context.path).get(context.id);
      if (!record || record[ownerField] !== ownerId) {
        throw new Error('Forbidden: resource not found or access denied');
      }
    }

    // For find, inject owner filter
    if (context.params.query) {
      context.params.query[ownerField] = ownerId;
    } else {
      context.params.query = { [ownerField]: ownerId };
    }

    return context;
  };
}

4. Audit and validate HMAC usage across services

Ensure that all services requiring HMAC apply the same ownership scoping logic. Review hooks and service definitions to confirm that no endpoint relies solely on HMAC without also binding the request to the authenticated principal’s scope. Combine HMAC with other transports (e.g., session cookies or JWTs) only when the security model explicitly allows it, and always enforce least-privilege access.