Broken Access Control in Restify with Mutual Tls

Broken Access Control occurs when an API fails to enforce proper authorization checks, allowing one user to access or modify data and functionality belonging to another. In Restify, enabling Mutual Transport Layer Security (Mutual TLS or mTLS) ensures that both client and server cryptographically authenticate each other using certificates. While mTLS strengthens authentication and integrity, it does not automatically enforce authorization. A common misconfiguration is to terminate mTLS at the gateway or load balancer and forward requests internally over plain HTTP without re-validating the mapped identity, or to rely solely on the client certificate for authorization without checking scopes, roles, or resource ownership.

In Restify, if you use mTLS to identify a client (e.g., via the certificate’s Common Name or Subject Alternative Name) but do not implement per-request authorization checks, you expose a BOLA/IDOR pattern. For example, an authenticated client certificate might be valid for user A, but the endpoint /users/:id/profile does not verify that the requesting identity matches the provided :id. An attacker who can influence the route parameter or chain requests through a compromised internal service can access or modify other users’ data despite mTLS being in place. This is a Broken Access Control issue because the authorization boundary is missing or misaligned with the authentication provided by mTLS.

Additionally, overly broad certificate issuance or weak certificate policies can exacerbate the risk. If a single client certificate is shared across multiple services or teams, or if certificate revocation is not handled promptly, the attack surface grows. In Restify, failing to validate certificate attributes such as extended key usage or to enforce fine-grained access rules based on certificate fields leads to privilege escalation or unauthorized operations. Proper authorization must be applied after mTLS authentication by mapping certificate claims to roles and permissions and enforcing them on every relevant route.

To securely combine mTLS with robust access control in Restify, you must authenticate via certificates and then enforce authorization checks on each request. Below are concrete, working examples that demonstrate how to configure mTLS and implement authorization in Restify.

1. Configure Mutual TLS in Restify

Use the https module to create a secure server with request certificate validation. This example loads the CA that signed client certificates and requires clients to present valid certificates.

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

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

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

With requestCert: true and rejectUnauthorized: true, Restify will only accept connections where the client provides a certificate signed by the specified CA. The authenticated client identity is available in the request object, typically via req.client.authorized and certificate fields.

2. Map Certificate Claims and Enforce Authorization

After mTLS authentication, extract identity and scopes from the client certificate and enforce RBAC or ABAC checks. For example, you can read the Common Name (CN) or custom extensions and compare them to the requested resource.

function getUserFromCert(cert) {
  // Example: cert.subject.CN might be 'user:12345'
  const match = cert.subject.CN.match(/^user:(.+)$/);
  return match ? match[1] : null;
}

server.pre((req, res, next) => {
  const cert = req.connection.getPeerCertificate();
  const userId = getUserFromCert(cert);
  if (!userId) {
    return res.send(401, { error: 'Unauthorized' });
  }
  // Attach identity to request for downstream handlers
  req.user = { id: userId, scopes: cert.extensions ? parseScopes(cert.extensions) : [] };
  return next();
});

function parseScopes(exts) {
  // Implement parsing of custom extensions or SANs as needed
  return [];
}

With the authenticated user attached to req.user, apply authorization in your routes. For a profile endpoint, ensure the requested user ID matches the authenticated user’s ID:

server.get('/users/:id/profile', (req, res, next) => {
  if (req.user.id !== req.params.id) {
    return res.send(403, { error: 'Forbidden: cannot access another user profile' });
  }
  // Fetch and return the profile for req.user.id
  const profile = getProfileForUser(req.user.id);
  return res.send(200, profile);
});

This pattern ensures that mTLS provides strong client authentication, while per-route checks enforce proper authorization, mitigating BOLA/IDOR and Broken Access Control. Combine this with logging and monitoring of certificate metadata to detect anomalies. Using tools like the middleBrick CLI (middlebrick scan <url>) can help validate that your mTLS setup does not inadvertently expose endpoints without authorization, and the GitHub Action can enforce a minimum security score before merging changes.