Bola Idor in Loopback with Hmac Signatures

BOLA (Broken Level Authorization) / IDOR occurs when one user can access or modify another user’s resources by manipulating identifiers such as IDs or slugs. In Loopback, this risk can manifest even when requests include HMAC signatures, if signature validation is limited to request authenticity and does not enforce ownership or authorization checks on the target resource.

Consider an endpoint like /api/users/{userId}/profile. A client computes an HMAC over the request method, path, timestamp, and body, then sends it in a header (e.g., x-api-signature). If the server validates the HMAC to confirm the request has not been tampered with, but then uses userId directly from the URL to fetch the profile without confirming that the authenticated subject owns that userId, a BOLA/IDOR flaw exists. An attacker who knows or guesses another user’s ID can forge a valid HMAC if the signing key is weak or if the timestamp/nonce validation is insufficient, or can simply reuse a captured request signed by a legitimate user. The signature proves the request was not modified in transit, but it does not prove the caller is allowed to access that specific resource.

Loopback context often involves multiple models and relations. If authorization logic is delegated only to method-level decorators or global hooks without verifying model-level ownership, the combination of HMAC integrity and missing ownership checks becomes dangerous. For example, an attacker might change userId in the URL to access another user’s data, and the server may still accept the request because the HMAC matches and the route is reachable without authentication challenges. This is especially relevant when endpoints expose numeric or predictable IDs and do not scope queries by the authenticated subject or by tenant/role boundaries.

Another scenario arises when HMACs are computed over a subset of headers or parameters, omitting critical authorization context such as an API key or a subject identifier. An attacker could reuse a signed request with a different path or parameter, relying on the server’s failure to revalidate scope. In Loopback, if the HMAC validation does not include the resource identifier in the signed string, or if timestamps/nonce checks are too permissive, the attack surface for BOLA/IDOR widens. Data exposure then follows: one user’s profile, settings, or linked sensitive records become accessible simply by iterating IDs and replaying validly signed requests.

Real-world parallels include cases where endpoints expose internal model IDs without scoping to the tenant or user. Even with HMAC integrity, without strict ownership checks and consistent authorization across all data access layers, BOLA/IDOR remains a practical threat. The vulnerability is not in HMAC itself, but in how its results are coupled with authorization decisions in Loopback’s request lifecycle.

To mitigate BOLA/IDOR when using HMAC signatures in Loopback, you must couple signature validation with explicit ownership and authorization checks at the data-access layer. The signature should cover all inputs that affect authorization, including the resource identifier, and verification must occur before any data fetch.

Below are concrete, syntactically correct examples for Loopback using Node.js. The first example shows how to compute and verify an HMAC that includes the user ID in the signed string, ensuring the signature is bound to the target resource.

const crypto = require('crypto');

function generateHmac(method, path, timestamp, userId, body, secret) {
  const payload = [
    method.toUpperCase(),
    path,
    timestamp,
    userId,
    typeof body === 'string' ? body : JSON.stringify(body)
  ].join('\n');
  return crypto.createHmac('sha256', secret).update(payload).digest('hex');
}

// Example usage inside a Loopback remote method
Profile.remoteMethod('getProfile', {
  accepts: { arg: 'userId', type: 'string', http: { source: 'path' } },
  http: { path: '/users/{userId}/profile', verb: 'get' },
});

Profile.getProfile = async function(userId, options = {}) {
  const { req } = options;
  const timestamp = req.headers['x-timestamp'];
  const receivedSignature = req.headers['x-api-signature'];
  const secret = process.env.HMAC_SECRET;

  if (!timestamp || !receivedSignature) {
    throw new Error('Missing signature or timestamp');
  }

  // Ensure timestamp is recent to prevent replay (e.g., within 5 minutes)
  const now = Date.now();
  const requestTs = parseInt(timestamp, 10);
  if (Math.abs(now - requestTs) > 5 * 60 * 1000) {
    throw new Error('Request timestamp out of allowed window');
  }

  const computedSignature = generateHmac(
    req.method,
    req.path,
    timestamp,
    userId,
    req.body || '',
    secret
  );

  if (!crypto.timingSafeEqual(Buffer.from(computedSignature), Buffer.from(receivedSignature))) {
    throw new Error('Invalid signature');
  }

  // Critical: enforce ownership/authorization after signature validation
  const currentUser = await getCurrentUser(req); // resolves subject from auth context
  if (!currentUser || currentUser.id !== userId) {
    throw new Error('Unauthorized: subject mismatch');
  }

  return Profile.findById(userId, { include: ['related'] });
};

The second example demonstrates scoping the data query by the authenticated subject rather than trusting the URL parameter alone. Even if the signature is valid, you should resolve the subject from the request context (e.g., from an API key or token) and use it in the query condition.

Profile.findOne({
  where: {
    AND: [
      { id: userId },           // resource identifier from URL
      { userId: currentUser.id } // authorization scope from authenticated context
    ]
  },
  include: ['related']
});

Additionally, include the minimal set of authorization-sensitive fields in the HMAC payload—such as user ID, method, path, and timestamp—and rotate the HMAC secret periodically. Combine this with Loopback’s built-in ACLs or custom role-based checks to ensure that even a valid signature does not bypass broader authorization policies. These steps close the gap where HMAC integrity alone would otherwise leave BOLA/IDOR feasible.