Data Exposure in Feathersjs with Hmac Signatures

FeathersJS is a framework for real-time web applications that frequently uses authentication hooks to secure services. When HMAC-based signatures are implemented for service-level authorization without strict validation of the request origin and payload integrity, the risk of data exposure can increase. A common pattern is to sign requests using a shared secret and verify the signature on the server to ensure the request has not been tampered with. However, if the signature is computed over only a subset of the request data or if the verification logic is inconsistent between client and server, an attacker may be able to infer or reconstruct sensitive information.

Consider a scenario where a FeathersJS service uses HMAC signatures to authorize create or update operations. If the server computes the HMAC over only selected fields (for example, excluding sensitive metadata) and then proceeds to apply the operation using the full untrusted payload, there is a mismatch between what was signed and what is executed. This mismatch can lead to data exposure when an attacker manipulates unsigned or weakly validated fields to inject or exfiltrate data. For instance, an attacker might modify a user ID field that was excluded from the signature to access or modify records belonging to other users, leading to unauthorized data exposure across tenants.

Additionally, if the HMAC signature is transmitted or logged in an insecure manner—such as being included in URLs, client-side JavaScript, or server logs without proper protection—it can be leaked to unauthorized parties. FeathersJS services that expose endpoints returning sensitive payloads without enforcing strict authorization checks after signature verification can inadvertently expose data. Even when the signature is valid, the service must still enforce record-level permissions and ensure that the authenticated subject is authorized to view or modify the specific resource. Without these checks, an attacker with a valid signature may still be able to traverse relationships or exploit overly broad service hooks to access data they should not see.

Real-world attack patterns involving weak HMAC usage in FeathersJS mirror issues seen in Insecure Direct Object References (IDOR) and Broken Function Level Authorization (BFLA). For example, an attacker may intercept a request containing a signed operation on a resource ID, then modify that ID while keeping the signature intact if the server does not recompute or scope the signature to the resource context. This can result in horizontal or vertical privilege escalation, where one user gains access to another user’s data. OWASP API Top 10 categories such as Broken Object Level Authorization and Excessive Data Exposure are relevant here, as the flaw resides in the authorization boundary rather than the cryptographic strength of the HMAC itself.

The use of HMAC in FeathersJS must be evaluated in the context of the full request lifecycle. If the framework’s hooks and services do not consistently apply the same verification logic across all relevant methods (find, get, create, update, patch), an attacker can exploit the weakest link to expose data. For instance, if the signature is verified only in a generic before hook but certain services override this behavior or skip the hook, data exposure can occur. Similarly, if the server reuses nonces or timestamps without proper validation, replay attacks may lead to the exposure of previously signed operations and the data they affect.

To summarize, data exposure arises in the combination of FeathersJS and HMAC signatures when there is inconsistency between what is signed and what is processed, insufficient authorization after verification, insecure transmission or storage of signatures, and gaps in hook execution. These issues do not imply a flaw in HMAC itself but highlight the importance of aligning the scope of the signed data with the actual operations performed and enforcing strict access controls at every layer of the service.

Remediation focuses on ensuring that the HMAC covers all relevant parts of the request, that verification is applied consistently, and that authorization checks are enforced after signature validation. Below are concrete code examples for a FeathersJS service that uses HMAC signatures for creating resources securely.

First, define a utility to compute the HMAC over a canonical representation of the payload and important metadata. Use a stable serialization method such as sorted JSON stringification to ensure both client and server produce the same input.

const crypto = require('crypto');

function computeHmac(payload, secret) {
  const normalized = JSON.stringify(payload, Object.keys(payload).sort());
  return crypto.createHmac('sha256', secret).update(normalized).digest('hex');
}

On the client side, include the computed signature in the request data or headers. Here, we add it to a custom header to keep the payload clean:

const secret = 'shared-secret';
const payload = {
  userId: '123e4567-e89b-12d3-a456-426614174000',
  email: '[email protected]',
  role: 'admin'
};
const signature = computeHmac(payload, secret);

fetch('/api/resource', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-API-Signature': signature
  },
  body: JSON.stringify(payload)
});

On the server side, in a FeathersJS before hook, verify the signature against the received payload and reject the request if they do not match. Ensure that the verification runs for all relevant methods and that the same normalization logic is used.

const crypto = require('crypto');

function verifyHmac(req, secret) {
  const signature = req.headers['x-api-signature'];
  if (!signature) {
    throw new Error('Missing signature');
  }
  const normalized = JSON.stringify(req.body, Object.keys(req.body).sort());
  const expected = crypto.createHmac('sha256', secret).update(normalized).digest('hex');
  if (!crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
    throw new Error('Invalid signature');
  }
}

module.exports = function() {
  const app = this;
  app.service('resource').before({
    create: [function(context) {
      verifyHmac(context, process.env.HMAC_SECRET);
      return context;
    }],
    update: [function(context) {
      verifyHmac(context, process.env.HMAC_SECRET);
      return context;
    }],
    patch: [function(context) {
      verifyHmac(context, process.env.HMAC_SECRET);
      return context;
    }]
  });
};

Additionally, enforce record-level authorization after the signature verification to prevent horizontal access across user boundaries. Combine the subject from the request context (e.g., from a session or an API key) with ownership checks on the resource.

app.service('resource').before({
  create: [
    function(context) {
      verifyHmac(context, process.env.HMAC_SECRET);
      // Assume context.params.user contains the authenticated subject
      context.data.userId = context.params.user.id;
      return context;
    }
  ],
  get: [
    function(context) {
      verifyHmac(context, process.env.HMAC_SECRET);
      return context;
    }
  ]
});

app.service('resource').hooks({
  after: {
    create: [function(context) {
      // Ensure the created resource belongs to the requesting user
      if (context.result.userId !== context.params.user.id) {
        throw new Error('Unauthorized');
      }
      return context;
    }]
  }
});

These examples demonstrate how to bind the HMAC to the exact payload and normalize inputs to avoid mismatches that lead to data exposure. Rotate secrets periodically, avoid logging signatures or sensitive payloads, and ensure that hooks are applied uniformly across all service methods to maintain consistent protection.