Fix Business Logic Errors in Feathers

FeathersJS simplifies CRUD, but its 'magic' often lures developers into a false sense of security. The most critical business logic flaw in Feathers is the lack of ownership verification during service calls. If you aren't explicitly scoping your queries to the authenticated user's ID, you're serving an IDOR (Insecure Direct Object Reference) on a silver platter. Attackers will simply swap the ID in a PATCH or DELETE request to manipulate data they don't own.

The Vulnerable Pattern

// services/messages/messages.hooks.js
module.exports = {
  before: {
    patch: [
      // VULNERABILITY: No check to see if the message actually belongs to the requester.
      // An attacker can send a PATCH to /messages/123 with their own data.
      authenticate('jwt')
    ]
  }
};

The Secure Implementation

The fix involves moving from 'Implicit Trust' to 'Identity-Bound Queries'. By using the `setField` hook (or a custom hook) to inject `params.user._id` into `params.query.userId`, we ensure the underlying database adapter adds a 'WHERE userId = current_user_id' clause to the operation. Even if an attacker targets a specific resource ID they don't own, the query will return a 404 because the record doesn't exist within their ownership scope. This effectively mitigates IDOR and unauthorized business logic bypasses at the service layer.

// services/messages/messages.hooks.js
const { setField } = require('feathers-hooks-common');
const { authenticate } = require('@feathersjs/authentication').hooks;
module.exports = {
before: {
patch: [
authenticate(‘jwt’),
// SECURE: Use setField to force the query to include the authenticated user’s ID.
// This ensures the update only succeeds if the record belongs to the user.
setField({
from: ‘params.user._id’,
as: ‘params.query.userId’
})
],
remove: [
authenticate(‘jwt’),
setField({
from: ‘params.user._id’,
as: ‘params.query.userId’
})
]
}
};