Bola Idor in Restify with Mutual Tls

BOLA (Broken Object Level Authorization) and IDOR (Insecure Direct Object References) occur when an API exposes internal object identifiers and lacks proper authorization checks per request. In a Restify service that also uses Mutual TLS (mTLS), the presence of mTLS can create a false sense of security and inadvertently change the attack surface in ways that enable BOLA/IDOR.

mTLS authenticates the client at the transport layer by validating a client certificate. Once the certificate is validated, the application may treat the request as fully authorized and skip higher-level authorization checks. For example, a Restify endpoint like /users/:userId/profile may verify that a TLS client certificate was presented and mapped to a user ID, then directly use :userId from the URL to fetch data. If the application does not confirm that the authenticated principal (derived from the certificate) is allowed to access the specific :userId, an attacker who obtains or guesses another user’s ID can retrieve or modify that resource. The mTLS handshake completes successfully, but the authorization boundary is missing, so the BOLA/IDOR exists despite the transport security.

Another scenario involves scoped or group-based access. mTLS can map a certificate to an identity and groups, but if the Restify handler only checks group membership once and then trusts the user-supplied object ID, horizontal privilege escalation becomes possible. For instance, an attacker might use a valid mTLS certificate belonging to a low-privilege user, iterate over numeric or UUID identifiers, and access other users’ data because the endpoint does not re-validate the relationship between the authenticated identity and the requested object. OpenAPI specs may reflect this hazard if parameters bound to object IDs are not tied to the authenticated subject in security schemes, enabling runtime mismatches between spec-defined auth and actual implementation.

Operational factors can amplify the issue. Because mTLS is often managed at an ingress or load balancer, developers may assume the environment enforces strict access control and omit per-request authorization logic. In a black-box scan, middleBrick can surface this risk by correlating unauthenticated endpoint behavior with missing authorization checks and misaligned security schemes in the OpenAPI definition. The 5–15 second scan tests the unauthenticated attack surface, and findings may highlight endpoints where object-level authorization is absent even when mTLS is in place.

Remediation centers on ensuring that mTLS-derived identity is explicitly used in authorization checks and that object-level access is validated for every request. Below are concrete Restify examples that combine mTLS certificate information with per-request BOLA/IDOR protections.

Example 1: Basic mTLS setup with identity-aware authorization

Configure Restify to require client certificates and extract identity in a verifiable way, then enforce ownership checks.

const restify = require('restify');
const fs = require('fs');

const server = restify.createServer({
  tls: {
    cert: fs.readFileSync('/path/server-cert.pem'),
    key: fs.readFileSync('/path/server-key.pem'),
    ca: [fs.readFileSync('/path/ca-cert.pem')],
    requestCert: true,
    rejectUnauthorized: true
  }
});

// Map the client certificate to an identity (e.g., from CN or a custom extension)
function getClientIdentity(req) {
  if (req.client.authorized && req.client.cert) {
    // Assuming certificate Common Name holds the user ID; in production use a robust mapping
    return req.client.cert.subject.CN;
  }
  return null;
}

server.get('/users/:userId/profile', (req, res, next) => {
  const authenticatedUserId = getClientIdentity(req);
  const requestedUserId = req.params.userId;

  // BOLA/IDOR guard: ensure the authenticated identity matches the requested resource
  if (!authenticatedUserId || authenticatedUserId !== requestedUserId) {
    return next(new restify.ForbiddenError('Unauthorized access to this resource'));
  }

  // Fetch profile for requestedUserId from data store (with own additional checks)
  const profile = getUserProfileFromStore(requestedUserId);
  if (!profile) {
    return next(new restify.NotFoundError('Profile not found'));
  }

  res.send(200, profile);
  return next();
});

server.listen(8080, () => {
  console.log('Server listening on port 8080');
});

Example 2: Group-based access with explicit mapping

When mTLS maps to groups, validate group-to-resource relationships on each request rather than relying on a cached decision.

function getUserGroupsFromCert(cert) {
  // Example: groups encoded in an extended field or mapped via a directory lookup
  return cert.extensions ? (cert.extensions.groups || []) : [];
}

server.post('/org/:orgId/resource/:resourceId', (req, res, next) => {
  const cert = req.client.cert;
  const userGroups = getUserGroupsFromCert(cert);
  const orgId = req.params.orgId;
  const resourceId = req.params.resourceId;

  // Verify that the user’s groups permit access to the org
  if (!userGroups.includes('org-admins') && !userGroups.includes(orgId)) {
    return next(new restify.ForbiddenError('Group-based access denied'));
  }

  // Additional BOLA check: confirm user has resource-level permission for resourceId
  if (!hasResourcePermission(cert.subject.CN, orgId, resourceId)) {
    return next(new restify.ForbiddenError('Insufficient resource permissions'));
  }

  // Proceed with operation
  const resource = fetchResource(orgId, resourceId);
  res.send(200, resource);
  return next();
});

Best practices summary

• Never treat mTLS authentication as implicit authorization; always map certificate identity to a subject and enforce object-level checks.
• Validate the relationship between the authenticated principal and the requested resource on every call, regardless of transport-layer guarantees.
• Use schema-driven security definitions (e.g., OpenAPI securitySchemes with x-mtls) to keep runtime checks aligned with design, and test these boundaries with scans that correlate spec and runtime behavior.