Broken Access Control in Restify with Bearer Tokens

Broken Access Control occurs when API endpoints do not properly enforce authorization checks, allowing authenticated users to access or modify resources that should be restricted. In Restify, a common pattern is to rely on Bearer Tokens for authentication but to omit or misconfigure authorization checks at the route or resource level. When Bearer Tokens are used without scoping or role verification, an authenticated user can change an identifier in a URL and access another user’s data or perform actions they should not be allowed to perform.

Consider a typical Restify route that retrieves a user profile by ID:

server.get('/profiles/:id', (req, res, next) => {
  const profileId = req.params.id;
  // Missing authorization check: any authenticated user can request any ID
  db.getProfile(profileId).then(profile => {
    res.send(profile);
  }).catch(next);
});

If the API only validates the presence of a Bearer Token in the Authorization header but does not verify that the requesting user is allowed to view the requested profile ID, this is a BOLA/IDOR (Broken Level of Authorization / Insecure Direct Object Reference) vulnerability. An attacker can iterate through numeric or predictable IDs and access other users’ profiles without needing to compromise the token itself.

Another scenario involves privilege escalation when role claims in a token are not validated server-side. For example, a token issued with scope or role "user" might be used to call an admin endpoint:

server.del('/admin/users/:userId', (req, res, next) => {
  // No check that the token's associated role is admin
  userService.deleteUser(req.params.userId).then(() => {
    res.send({ deleted: true });
  }).catch(next);
});

Here, the absence of role-based checks enables a user with a low-privilege token to invoke an administrative operation. This maps directly to the BFLA/Privilege Escalation checks in middleBrick’s 12 security checks. Even when Bearer Tokens are used, the API must enforce authorization on every request, validating both the identity and the permissions encoded in the token (e.g., via scopes or roles) before allowing access.

middleBrick’s scan for this endpoint would flag missing property or role authorization as a high-severity finding, referencing the OWASP API Top 10 A01:2023 — Broken Access Control. The scanner also cross-references the OpenAPI spec’s security schemes with runtime behavior to detect when authentication is present but authorization is incomplete. Remediation focuses on ensuring every route that accesses or modifies resources validates the subject’s permissions against the resource and the action being performed.

Remediation centers on explicitly checking token claims and resource ownership in each handler. Below are concrete, working examples for Restify that demonstrate proper authorization with Bearer Tokens.

1. Validate ownership by comparing token subject with resource owner

Ensure that the requesting user can only access their own data:

server.get('/profiles/:id', (req, res, next) => {
  const profileId = req.params.id;
  const tokenUserId = req.claims.sub; // subject from validated JWT
  if (String(profileId) !== String(tokenUserId)) {
    return res.send(403, { error: 'forbidden', message: 'You can only view your own profile' });
  }
  db.getProfile(profileId).then(profile => {
    res.send(profile);
  }).catch(next);
});

This check prevents IDOR by comparing the resource identifier with the user identifier embedded in the token claims, rather than trusting the URL parameter alone.

2. Enforce role-based access control (RBAC) for admin operations

Verify roles or scopes before allowing privileged actions:

server.del('/admin/users/:userId', (req, res, next) => {
  const tokenScopes = req.claims.scopes || [];
  const hasAdminScope = tokenScopes.includes('admin:users:delete');
  if (!hasAdminScope) {
    return res.send(403, { error: 'insufficient_scope', message: 'Admin scope required' });
  }
  userService.deleteUser(req.params.userId).then(() => {
    res.send({ deleted: true });
  }).catch(next);
});

Alternatively, if roles are used:

server.del('/admin/users/:userId', (req, res, next) => {
  const tokenRoles = req.claims.roles || [];
  const isAdmin = tokenRoles.includes('admin');
  if (!isAdmin) {
    return res.send(403, { error: 'forbidden', message: 'Admin role required' });
  }
  userService.deleteUser(req.params.userId).then(() => {
    res.send({ deleted: true });
  }).catch(next);
});

These examples show how to couple Bearer Token validation with explicit authorization logic. The token must be validated earlier in the middleware stack (e.g., via JWT verification), and the handler must then inspect claims for subject and permissions before proceeding.

middleBrick’s CLI can be used to verify these fixes by rescoring the endpoint after changes:

# Scan your API after implementing authorization checks
middlebrick scan https://api.example.com

Using the GitHub Action allows you to enforce a minimum score in CI/CD, so future changes that reintroduce missing authorization cause the build to fail. The MCP Server lets you run the same scan directly from your IDE while developing, helping you catch access control gaps early.