Bola Idor in Loopback with Bearer Tokens

BOLA (Broken Object Level Authorization) / IDOR occurs when an API fails to enforce proper authorization checks at the object level, allowing one subject to access or modify resources that belong to another subject. In LoopBack, this commonly arises when an endpoint identifies a resource by an identifier (e.g., /users/123/profile) but only validates that a Bearer Token is present and valid, without verifying that the token’s subject is permitted to operate on that specific resource.

Consider a typical LoopBack setup where an access token contains a user identifier (e.g., sub) and the server uses built-in authentication components to verify the token. If a developer writes a remote method like UserProfile.findById that relies on route parameters (such as id) without cross-checking the authenticated subject, an attacker can change the ID in the request. For example, an authenticated user with ID 1001 could modify the request path to /user-profiles/1002 and, in the absence of explicit ownership checks, potentially view or alter another user’s profile. The presence of a Bearer Token gives the request credibility, but the missing relationship check between token subject and resource ownership creates the BOLA/IDOR condition.

This risk is compounded when token introspection or authorization logic is performed at a coarse granularity, such as only verifying scopes or roles without inspecting the resource’s owning user or tenant. In LoopBack, it’s not enough to confirm that a token is valid; you must ensure that every data-access method validates that the authenticated subject matches the resource’s owning entity. Without this, the API surface remains vulnerable to horizontal privilege abuse, where one user can iterate over identifiers to access others’ data, and to vertical privilege abuse if role-based assumptions incorrectly grant broader access than intended.

Real-world attack patterns include enumeration of identifiers through authenticated requests, where an attacker iterates over numeric or UUID identifiers while monitoring responses for differences in data returned or timing. In a LoopBack API that exposes user settings, transaction history, or configuration objects, missing ownership checks on these endpoints enable unauthorized read and potentially write operations. The combination of a trusted Bearer Token and insufficient object-level authorization transforms what should be a benign authenticated request into a pathway for data exposure or manipulation, aligning with OWASP API Top 10 A1: Broken Object Level Authorization.

To detect this during a scan, middleBrick runs checks that compare authenticated identity claims present in Bearer Tokens with resource ownership metadata returned by the API. It maps findings to relevant compliance frameworks such as OWASP API Top 10 and SOC2, highlighting where token-based authentication exists but object-level authorization is missing. The scanner does not fix the logic, but the findings include remediation guidance to tighten authorization checks so that resource access is explicitly tied to the authenticated subject.

Remediation focuses on ensuring that every resource access validates the relationship between the authenticated subject and the target object. Below are concrete patterns and code snippets for LoopBack that demonstrate secure handling of Bearer Tokens.

1. Enforce ownership checks in remote methods

Instead of relying on route parameters alone, bind the authenticated subject from the token to the query or filter. For example, if a user can only access their own profile:

// In src/controllers/user-profile.controller.ts
import {repository} from '@loopback/repository';
import {param, requestContext} from '@loopback/rest';
import {UserProfileRepository} from '../repositories';

export class UserProfileController {
  constructor(
    @repository(UserProfileRepository)
    public userProfileRepository: UserProfileRepository,
  ) {}

  @get('/user-profiles/{id}', {
    responses: {
      '200': {
        description: 'User profile',
        content: {'application/json': {schema: {'type': 'object'}}},
      },
    },
  })
  async getUserProfile(
    @param.path.string('id') requestedId: string,
    @requestContext() ctx: RequestContext,
  ): Promise<UserProfile> {
    const userId = ctx.principals?.find(p => p.name === 'user')?.id as string;
    if (!userId) {
      throw new HttpErrors.Unauthorized('Authentication required');
    }
    if (userId !== requestedId) {
      throw new HttpErrors.Forbidden('Access denied: cannot access other user resources');
    }
    return this.userProfileRepository.findById(requestedId);
  }
}

2. Use model hooks to enforce ownership at the data-access layer

LoopBack’s model hooks allow centralized checks before a find or update operation. Use the beforeRemote hook to verify that filters respect the authenticated subject:

// In src/models/user.model.ts
import {Model} from '@loopback/repository';
import {post, model} from '@loopback/repository';
import {authenticationBindings, UserProfile} from '../keys';
import {inject} from '@loopback/core';
import {HttpErrors} from '@loopback/rest';

@model({
  name: 'UserProfile',
  strict: false,
})
export class UserProfileModel extends Model {
  constructor(
    @inject(authenticationBindings.CURRENT_USER, {optional: true})
    public currentUser: UserProfile | null,
  ) {
    super();
  }

  public static hooks(hookManager: any) {
    hookManager.before('find', (ctx, next) => {
      const user = ctx.options?.context?.currentUser;
      if (!user) {
        throw new HttpErrors.Unauthorized('Authentication required');
      }
      // Ensure the filter restricts to the authenticated user
      const filter = ctx.args.filter || {};
      if (!filter.where) filter.where = {};
      filter.where.userId = user.id;
      ctx.args.filter = filter;
      next();
    });
  }
}

3. Validate ownership in custom repositories

When using repositories, add explicit checks before performing operations:

// In src/repositories/user-profile.repository.ts
import {injectable} from '@loopback/core';
import {DefaultCrudRepository} from '@loopback/repository';
import {UserProfileRepository, UserProfileRelations} from '../repositories';
import {HttpErrors} from '@loopback/rest';

@injectable()
export class UserProfileRepository extends DefaultCrudRepository<
  UserProfile,
  typeof UserProfile.prototype.id,
  UserProfileRelations
> {
  constructor(
    @inject(authenticationBindings.CURRENT_USER)
    public currentUser: any,
  ) {
    super(UserProfile, dataSource);
  }

  async findByIdWithOwnership(id: string, options?: any) {
    const user = this.currentUser;
    if (!user) {
      throw new HttpErrors.Unauthorized('Authentication required');
    }
    const entity = await this.findById(id, options);
    if (entity.userId !== user.id) {
      throw new HttpErrors.Forbidden('Access denied: resource does not belong to caller');
    }
    return entity;
  }
}

4. Securely parse and use Bearer Tokens in LoopBack middleware

Ensure the token is validated and the subject is extracted and attached to the request context. If using LoopBack’s built-in auth, confirm that the token’s sub or a custom claim maps to a principal that you later compare with resource ownership:

// Example of extracting user ID from JWT in a custom action decorator
import {decorators, requestContext} from '@loopback/rest';
import {authenticate} from '@loopback/authentication';

export const requireOwnership = (modelName: string) =>
  decorators.intercept(
    requestContext({
      interceptors: [
        async (ctx, next) => {
          const currentUser = ctx.requestContext.getSync(authenticationBindings.CURRENT_USER_SECURITY_ID);
          const paramId = ctx.args.id as string;
          // Fetch resource and compare IDs
          const resource = await someRepo.findById(paramId);
          if (resource.ownerId !== currentUser) {
            throw new HttpErrors.Forbidden('Not owner');
          }
          return next();
        },
      ],
    }),
  );

5. Use scopes and roles with resource-level checks

Roles and scopes can reduce broad access but must not replace object-level checks. For example, an admin scope might allow broader access, but you should still validate that an admin is acting within policy-defined boundaries when accessing user-specific data:

// In a repository or service method
async updateSensitive(dataId: string, update: Partial<SensitiveData>, ctx: RequestContext) {
  const principal = ctx.principals?.find(p => p.name === 'scope');
  const isAdmin = principal?.scopes?.includes('admin');
  const data = await this.dataRepo.findById(dataId);
  if (!isAdmin && ctx.principals?.[0]?.id !== data.ownerId) {
    throw new HttpErrors.Forbidden('Insufficient permissions');
  }
  // proceed with update
}

By combining token validation with explicit resource ownership checks, you mitigate BOLA/IDOR risks even when Bearer Tokens are used for authentication. These patterns keep authorization tight and prevent attackers from leveraging a valid token to traverse or manipulate other users’ resources.

middleBrick’s scanner can surface where endpoints authenticate with Bearer Tokens but lack object-level authorization, providing findings mapped to OWASP API Top 10 and guidance to implement the controls shown above.