Broken Access Control in Loopback with Bearer Tokens

Broken Access Control in Loopback using Bearer Tokens arises when authorization checks are missing or incorrectly applied at the loopback endpoint, allowing an authenticated user to access or modify resources that should be restricted. This typically occurs when role-based or ownership-based rules are not enforced at the model or controller level, even though a valid Bearer Token is presented to authenticate the request.

In a Loopback application, authentication via Bearer Token is commonly handled by an authentication component (such as loopback-component-passport or custom JWT strategies) that sets req.user on incoming requests. Authorization, however, must be implemented explicitly. If routes or model ACLs rely only on authentication and do not validate roles, scopes, or resource ownership, an attacker can use a valid token for one privilege level to perform actions reserved for another. For example, a user with a standard read-only token might be able to call an admin-only endpoint if the controller does not verify role membership.

The unauthenticated attack surface tested by middleBrick includes scenarios where an endpoint appears to require authentication but does not enforce proper authorization checks on incoming Bearer Tokens. Without robust scope or role validation, attackers can leverage low-privilege tokens to escalate privileges horizontally or vertically. Common patterns that contribute to this include permissive model ACLs, missing accessScopes checks, and routes that infer identifiers from user input without verifying that the target resource belongs to the requesting user.

Consider a Loopback model Account with an ACL that inadvertently allows any authenticated user to read other users’ data. If the ACL is defined as 'accessType': 'READ' with 'principalType': 'ROLE' and 'principalId' is not tightly scoped, a bearer token from one user may grant access to another user’s data. This misconfiguration maps to common OWASP API Top 10 categories such as Broken Object Level Authorization (BOLA), which middleBrick flags under its BOLA/IDOR checks.

Real-world attack patterns include enumeration via predictable numeric IDs in endpoints like /api/accounts/{id}, where a valid Bearer Token is reused across different identifiers without ownership verification. Similarly, missing scope validation on OAuth2-style tokens can allow a token with broad permissions to be used in contexts where least privilege should apply. middleBrick’s parallel security checks identify these weaknesses by correlating OpenAPI/Swagger spec definitions with runtime behavior, highlighting discrepancies between declared and enforced access controls.

Remediation focuses on enforcing authorization on every request that accesses or modifies data, using the Bearer Token’s claims to enforce least privilege. In Loopback, define precise ACLs on models and enforce scope and role checks in remote methods or operations. Avoid relying solely on authentication middleware to determine what a user can do.

First, structure your ACLs to include granular property, accessScope, and principalId entries. For example, an ACL that allows users to manage only their own profiles might look like:

{
  "principalType": "ROLE",
  "principalId": "$everyone",
  "accessType": "EXECUTE",
  "permission": "DENY"
},{
  "principalType": "ROLE",
  "principalId": "$authenticated",
  "accessType": "READ",
  "permission": "ALLOW",
  "property": "profile",
  "accessScope": "{ 'userId': '${context{userId}' }"
},{
  "principalType": "ROLE",
  "principalId": "$authenticated",
  "accessType": "WRITE",
  "permission": "ALLOW",
  "property": "updateAttributes",
  "accessScope": "{ 'userId': '${context{userId}} }"
}

Second, in your model’s JavaScript configuration or within a remote hook, validate that the token’s scopes or roles align with the requested operation. Using Loopback’s context, you can compare the requesting user ID to the resource owner ID before proceeding:

Account.observe('access', function restrictAccessToOwner(ctx, next) {
  if (ctx.query && ctx.query.where) {
    const userId = ctx.req && ctx.req.accessToken && ctx.req.accessToken.userId;
    if (userId) {
      ctx.query.where.userId = userId;
    } else {
      const err = new Error('Unauthorized');
      err.statusCode = 401;
      return next(err);
    }
  }
  next();
});

For remote methods, explicitly check roles or scopes before performing sensitive actions:

Account.prototype.adminAction = function(options, cb) {
  const user = this.app.models.User;
  const token = this.app.get('current-request-context')?.get('req')?.req?.accessToken;
  if (!token) {
    return cb(new Error('Unauthorized'));
  }
  user.findById(token.userId, function(err, userInstance) {
    if (err) return cb(err);
    if (!userInstance || !userInstance.hasRole('admin')) {
      return cb(new Error('Insufficient permissions'));
    }
    // Proceed with admin action
    cb(null, 'success');
  });
};

Additionally, prefer using short-lived Bearer Tokens with scope claims and validate scopes on each request. Configure your authentication strategy to emit structured tokens containing roles and scopes, and enforce those claims in Loopback’s access controls. This approach reduces the impact of token leakage and ensures that even with a valid Bearer Token, the blast radius of compromised credentials is limited.