Fix BFLA (Broken Function Level Authorization) in LoopBack

BFLA (Broken Function Level Authorization) is a critical vulnerability where an API relies on the client to hide administrative functions instead of enforcing permissions server-side. In LoopBack 4, simply adding '@authenticate' is insufficient; that only verifies identity (Authentication). Without '@authorize', any authenticated user can hit sensitive endpoints like user deletion or configuration changes. This guide demonstrates how to lock down controllers using LoopBack's authorization component.

The Vulnerable Pattern

@post('/admin/delete-user/{id}')
@authenticate('jwt')
async deleteUser(@param.path.string('id') id: string): Promise {
  // VULNERABILITY: Any logged-in user (even a 'guest') can call this
  // because there is no role or permission check.
  await this.userRepository.deleteById(id);
}

The Secure Implementation

The fix involves three layers: 1. Mount the '@loopback/authorization' component in your Application class. 2. Implement an 'AuthorizationProvider' (voter) that inspects the current user's principal (claims) against the required roles. 3. Explicitly decorate every sensitive controller method with '@authorize'. In the secure example, the 'basicAuthorization' voter compares the user's 'ADMIN' role against the endpoint's requirements. If the role is missing, LoopBack returns a 403 Forbidden before the function logic ever executes, preventing unauthorized state changes.

import {authorize} from '@loopback/authorization';
@post(‘/admin/delete-user/{id}’)
@authenticate(‘jwt’)
@authorize({
allowedRoles: [‘ADMIN’],
voters: [basicAuthorization],
})
async deleteUser(@param.path.string(‘id’) id: string): Promise {
// SECURE: The AuthorizationComponent intercepts the request
// and validates the user’s roles against the required metadata.
await this.userRepository.deleteById(id);
}