Fix BOLA (Broken Object Level Authorization) in LoopBack
BOLA (Broken Object Level Authorization) is the apex predator of API vulnerabilities. In LoopBack 4, this occurs when your controllers blindly trust the 'id' parameter from the request path without verifying that the authenticated principal actually owns the requested resource. If you aren't scoping your repository queries to the current user's ID, you're handing out a skeleton key to your database.
The Vulnerable Pattern
@get('/orders/{id}')
async findById(@param.path.string('id') id: string): Promise {
// VULNERABLE: Fetches any order by ID regardless of who is asking.
// An attacker can iterate IDs to scrape the entire database.
return this.orderRepository.findById(id);
}
The Secure Implementation
To kill BOLA, you must enforce authorization at the database query level. The fix involves three steps: 1. Use the @authenticate decorator to ensure a valid session. 2. Inject the SecurityBindings.USER to retrieve the authenticated user's identity. 3. Replace findById() with findOne(), passing a filter that mandates both the resource ID and the ownerId match. This ensures that even if an attacker guesses a valid UUID, the database will return null because the ownership check fails, effectively neutralizing the IDOR/BOLA vector.
@authenticate('jwt') @get('/orders/{id}') async findById( @param.path.string('id') id: string, @inject(SecurityBindings.USER) currentUser: UserProfile ): Promise{ // SECURE: Scope the query by both the resource ID and the owner ID. const order = await this.orderRepository.findOne({ where: { id: id, ownerId: currentUser[securityId] } });
if (!order) { throw new HttpErrors.NotFound(‘Order not found’); } return order; }
About this page
Framework notes in /guides are generated sketches kept for URL stability. They are not human pentest reports and they are not GuardAPI scan output. The product is a GET-only BOLA merge gate. Maintained by GuardAPI. Questions: support@guard-api.com