Bola Idor in Hapi with Mutual Tls

BOLA (Broken Level Authorization) / IDOR occurs when an API exposes an identifier (e.g., a resource ID) without ensuring that the requesting actor is authorized to access that specific instance. In Hapi, this commonly arises when route handlers use user-supplied IDs to fetch records (e.g., /users/{id}) and skip an ownership or role check. Adding Mutual TLS (mTLS) secures transport and strongly authenticates clients via certificates, but it does not automatically enforce object-level authorization. Relying only on mTLS can therefore create a false sense of security: once a client proves its identity, the endpoint may implicitly trust the identity and expose BOLA/IDOR if the handler does not validate that the resource belongs to or is accessible to that client.

For example, a Hapi server using mTLS might verify that a request includes a valid client certificate, but if the route /accounts/{accountId} uses the certificate’s subject or a mapped user ID to look up accounts without confirming that the authenticated user owns or is permitted to view that account, attackers can enumerate valid IDs and access other users’ data. This is a classic BOLA/IDOR rooted in missing authorization logic rather than weak transport security. OpenAPI specifications that define path parameters and security schemes help highlight these risks when spec definitions are cross-referenced with runtime behavior during scans.

Consider a handler that retrieves an account using an ID from the URL while only checking that a certificate is present:

// Risk: BOLA/IDOR — missing ownership check despite mTLS authentication
server.route({
  method: 'GET',
  path: '/accounts/{accountId}',
  options: {
    auth: false // mTLS handled via server TLS options, not route auth
  },
  handler: async (request, h) => {
    const { accountId } = request.params;
    const { user } = request.auth; // certificate mapped to user
    // Missing: verify that user owns or has access to accountId
    const account = await db.accounts.get(accountId);
    return account;
  }
});

An attacker with a valid certificate could iterate numeric or predictable accountId values and access accounts belonging to other users. mTLS ensures a trusted client identity but does not prevent this class of authorization flaw. Compounded risks appear when mTLS is used alongside weak inventory management or unsafe consumption patterns, increasing the likelihood of exposure.

To fix BOLA/IDOR in Hapi while using Mutual TLS, combine mTLS for client authentication with explicit, per-request authorization checks that validate the relationship between the authenticated identity and the requested resource. Do not rely on mTLS alone for object-level permissions. Define a route auth strategy that maps the client certificate to a user identity, then enforce ownership or role-based checks within the handler or via an authorization layer.

Example: configure Hapi with TLS options and a basic mapping from certificate fields to a user, then enforce account ownership in the route handler:

const Hapi = require('@hapi/hapi');
const fp = require('hapi-auth-fastify');

const validate = async (request, decoded) => {
  // 'decoded' can be populated from a certificate-to-user mapping step
  return { isValid: true, credentials: decoded };
};

const server = Hapi.server({
  port: 443,
  tls: {
    key: fs.readFileSync('server-key.pem'),
    cert: fs.readFileSync('server-cert.pem'),
    ca: [fs.readFileSync('ca-cert.pem')],
    requestCert: true,
    rejectUnauthorized: true
  }
});

// Map certificate to a user (simplified)
const certificateToUser = (cert) => {
  const subject = cert.subject;
  // Extract a stable identifier, e.g., email or a UUID from SAN or CN
  return { id: subject.Email, role: 'user' };
};

server.auth.strategy('certAuth', 'custom', {
  validate: validate
});

server.route({
  method: 'GET',
  path: '/accounts/{accountId}',
  options: {
    auth: 'certAuth',
    handler: async (request, h) => {
      const { accountId } = request.params;
      const user = request.auth.credentials; // mapped from client cert
      // Enforce BOLA/IDOR: ensure user can access this account
      const account = await db.accounts.get(accountId);
      if (!account) {
        throw Boom.notFound();
      }
      if (account.userId !== user.id && user.role !== 'admin') {
        throw Boom.forbidden('Unauthorized access to this account');
      }
      return account;
    }
  }
});

await server.start();

For stronger assurance, use an authorization layer or policy engine to centralize checks and reduce duplication. When using OpenAPI specs, ensure path and security scheme definitions reflect the requirement for both mTLS and object-level permissions; this alignment helps scanners detect mismatches between transport security and missing authorization controls. middleBrick’s OpenAPI/Swagger spec analysis can surface such gaps by comparing spec definitions with runtime behavior, especially valuable when scans include LLM-specific checks that test for exposed endpoints or missing constraints.

Finally, apply least-privilege principles to certificate issuance and map certificates to granular roles or scopes. Combine mTLS with explicit ownership or tenant checks, avoid trusting identifiers solely from the client, and log authorization denials for audit. These steps mitigate BOLA/IDOR in Hapi while preserving the security benefits of Mutual TLS.