Bola Idor in Strapi with Hmac Signatures

BOLA (Broken Level of Authorization) and IDOR (Insecure Direct Object References) occur when an API exposes internal object identifiers and lacks proper authorization checks per request. Strapi, a headless CMS, exposes REST and GraphQL endpoints that often map directly to content entries identified by numeric or UUID primary keys. When these endpoints rely only on user authentication (e.g., JWT) without per-object ownership or tenant checks, attackers can modify the identifier in the request and access or modify other users’ data.

Combining Strapi with Hmac Signatures can inadvertently create or expose BOLA/IDOR when the signature is used to bind a resource to a client but is not verified with strict scope and integrity checks. A common pattern is to generate an Hmac over a resource identifier (e.g., entry ID) and a timestamp, then send that Hmac as a query parameter or header. If the server uses the Hmac only to confirm the value has not changed, but does not re-validate that the authenticated user is allowed to access the referenced object, the Hmac does not prevent BOLA/IDOR. An attacker who can view a valid Hmac for another user’s resource can replay the request; if the server trusts the Hmac and skips authorization, the attacker can read or mutate data they should not see.

For example, a Strapi endpoint might be called with GET /api/articles/{id}?signature=HMAC(entryId, timestamp). The server verifies the Hmac to ensure the entry ID has not been tampered with but does not confirm that the requesting user belongs to the same organization or owns that entry. Because the Hmac is static for a given entry and key, an attacker can reuse a captured signature to enumerate IDs (IDOR) or to escalate by targeting entries they do not own (BOLA).

Risk increases when the Hmac is derived from secrets stored server-side and the endpoint exposes predictable identifiers. Without additional per-request context (such as the user’s allowed scopes or tenant ID), the Hmac becomes a weak perimeter. Attack patterns similar to CVE-2022-25883 (unauthorized access via predictable IDs) and general OWASP API Top 10 A01:2023 broken access control map to this scenario. The presence of Hmac signatures should not replace robust authorization; it should complement scoped, user-aware checks that validate every request against the requester’s permissions.

To remediate BOLA/IDOR when using Hmac Signatures in Strapi, ensure the signature covers not only the resource identifier but also the user or tenant context, and enforce authorization checks after signature verification. Use a server-side secret, include the user ID or tenant ID, the entry ID, and a short-lived timestamp to prevent replay. Always verify the user’s permission to access the specific resource before returning data.

Example Hmac generation on the client (Node.js):

const crypto = require('crypto');

function buildHmac(entryId, userId, secret, expiresInSec = 300) {
  const timestamp = Math.floor(Date.now() / 1000);
  const expires = timestamp + expiresInSec;
  const payload = `${entryId}:${userId}:${timestamp}:${expires}`;
  const signature = crypto.createHmac('sha256', secret).update(payload).digest('hex');
  return { signature, timestamp, expires };
}

// Example usage:
// const { signature, timestamp, expires } = buildHmac('123', 'user-456', process.env.HMAC_SECRET);

Example Hmac verification in Strapi (custom middleware or controller):

const crypto = require('crypto');

function verifyHmac(entryId, userId, timestamp, expires, signature, secret) {
  const now = Math.floor(Date.now() / 1000);
  if (now > expires) return false;
  const payload = `${entryId}:${userId}:${timestamp}:${expires}`;
  const expected = crypto.createHmac('sha256', secret).update(payload).digest('hex');
  // Use timing-safe compare to avoid timing attacks
  return crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
}

// In a Strapi controller:
module.exports = {
  async findOne(ctx) {
    const { id } = ctx.params;
    const { signature, timestamp, expires, userId } = ctx.query;
    const hmacSecret = strapi.config.get('plugin.hmac.secret');

    if (!hmacSecret) {
      return ctx.badRequest('Server configuration error');
    }

    if (!verifyHmac(id, userId, timestamp, expires, signature, hmacSecret)) {
      return ctx.unauthorized('Invalid or expired signature');
    }

    // Enforce authorization: ensure the entry belongs to the requesting user or tenant
    const entry = await strapi.entityService.findOne('api::article.article', id, {
      populate: { author: { select: ['id'] } },
    });

    if (!entry || String(entry.author) !== String(userId)) {
      return ctx.forbidden('Access denied');
    }

    return entry;
  },
};

Key practices to prevent BOLA/IDOR with Hmac Signatures in Strapi:

• Include user or tenant context in the Hmac payload so a signature is not portable across users.
• Use short expiration windows (e.g., 5 minutes) and a timestamp to mitigate replay attacks.
• Always perform server-side authorization after signature validation; never rely on the Hmac alone for access control.
• Use crypto.timingSafeEqual for signature comparisons to avoid timing-based side channels.
• Avoid exposing internal IDs directly; consider mapping IDs to opaque tokens if necessary, and validate mapping server-side.