Broken Access Control in Restify with Api Keys

Broken Access Control occurs when API endpoints fail to enforce proper authorization checks, allowing one user to access or modify another user's resources. In Restify, using only Api Keys for authorization can create this vulnerability when key-to-role or key-to-tenant mappings are not validated on every request. If an endpoint relies on a key to identify a service or application, but does not additionally verify that the key grants access to the specific resource being requested, an attacker can use a valid key to traverse IDs (BOLA/IDOR) or exploit misconfigured privilege boundaries.

Consider a Restify service that authenticates requests via an X-API-Key header but then loads a user profile using a user-supplied userId parameter. If the service does not confirm that the API key is authorized for that userId, an authenticated attacker can enumerate or manipulate user IDs to access or change other users' data. This is a BOLA/IDOR issue rooted in authorization logic, not authentication. Even when keys rotate, missing per-request authorization checks keep the surface open.

Another common pattern in Restify is attaching scopes or roles to keys via middleware, but failing to re-check those scopes on downstream routes or when route parameters change. For example, a key with admin:read might be allowed to list all users, but if the handler for /users/:id does not ensure the key also has admin:user:read for the specific :id, an attacker can increment IDs to escalate insight into other admin accounts. The vulnerability is amplified when responses include sensitive fields like emails or internal identifiers, contributing to Data Exposure findings under the API security checks run by middleBrick.

Because middleBrick scans unauthenticated endpoints, it can detect endpoints that accept Api Keys yet expose user-specific identifiers without proper ownership checks. Findings often include a reference to BOLA/IDOR and may map to OWASP API Top 10 A01:2023 — Broken Access Control, as well as relevant regulatory considerations in frameworks such as GDPR and SOC2. middleBrick also highlights cases where keys are accepted but role or tenant context is absent from route handlers, providing prioritized remediation guidance tied to the scan output.

To fix Broken Access Control when using Api Keys in Restify, explicitly validate that each key maps to allowed actions and data for the requested resource. Do not treat the key as a complete authorization token; instead combine it with per-request checks against a permissions model that includes user or tenant context. The following examples illustrate a robust pattern.

First, maintain a lookup that resolves an API key to an authorized scope and associated tenant or user set. Then, in each handler, confirm that the requested resource belongs to that scope before proceeding.

const restify = require('restify');
const server = restify.createServer();

// Example in-memory mapping; replace with a secure data source
const apiKeyPermissions = {
  'key-service-a': { scopes: ['read:users'], allowedUserIds: new Set(['u1', 'u2']) },
  'key-service-b': { scopes: ['read:users', 'write:users'], allowedUserIds: new Set(['u3']) }
};

server.pre((req, res, next) => {
  const key = req.headers['x-api-key'];
  if (!key || !apiKeyPermissions[key]) {
    return next(new restify.UnauthorizedError('Invalid or missing API key'));
  }
  req.auth = apiKeyPermissions[key];
  return next();
});

server.get('/users/:id', (req, res, next) => {
  const { id } = req.params;
  const { allowedUserIds } = req.auth;
  // BOLA/IDOR mitigation: ensure the key is allowed for this specific user id
  if (!allowedUserIds.has(id)) {
    return next(new restify.ForbiddenError('Access denied for this user'));
  }
  // proceed to fetch user data safely
  res.send({ id, name: 'Example User' });
  return next();
});

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

In this pattern, the pre hook validates the Api Key and enriches the request with permission metadata. The route handler then performs an explicit check against the resource identifier, ensuring that a valid key does not automatically imply access to all identifiers. This aligns with remediations often recommended in middleBrick findings, where missing property-level authorization is flagged.

For endpoints that involve tenant or organization context, include a tenant ID in both the key mapping and the request parameters, and assert equality before accessing data. Avoid relying on client-supplied IDs alone; always cross-reference them with the permissions resolved from the key. When using middleware to assign roles, recompute or re-validate those roles per request rather than caching them in request-local state that bypasses checks.

Adopting this approach reduces the likelihood of BOLA/IDOR and Privilege Escalation findings in scans performed by tools like middleBrick. The CLI (middlebrick scan <url>) and the GitHub Action can then verify that your Restify endpoints require both a valid Api Key and proper resource ownership, giving you continuous visibility into authorization hygiene.