If you had to choose a single class of vulnerability most likely to result in a customer data breach at a modern SaaS company, it would not be SQL injection or XSS. It would be Broken Object Level Authorization — BOLA for short, and ranked number one in the OWASP API Security Top 10 for good reason. Its close cousin, Broken Function Level Authorization (BFLA), rounds out the pair. Together they account for the majority of high-severity API findings in security assessments, and they share one critical property: automated scanners almost never find them.
TL;DR: BOLA lets a user access another user's data by changing an object ID. BFLA lets a regular user call admin-only functions because role enforcement is missing at the endpoint level. Both require multi-account manual testing to find. They are the #1 and #5 risks in the OWASP API Security Top 10 and are consistently the highest-impact findings in API penetration tests.
What Is BOLA?
Broken Object Level Authorization occurs when an API authenticates that you are a valid user but fails to verify that the specific object you are requesting belongs to you. The classic pattern: you are logged in as User A and make a request to GET /api/v1/invoices/8821. Your API returns the invoice. Now you change the ID to GET /api/v1/invoices/8820. If the API returns another customer's invoice rather than a 403, you have BOLA.
The reason this is so common is architectural. Authentication — proving who you are — is typically implemented once as middleware that applies to all routes. Authorization — proving you have permission to access this specific resource — has to be implemented individually for every endpoint that returns object data. Under development pressure, teams get authentication right and shortcut authorization. The result is an API that knows you are logged in but does not know whether the order, document, user record, or payment you requested is yours.
Real-world examples
BOLA is not a theoretical vulnerability. It has appeared in some of the most significant API data exposures of recent years:
- Venmo's public transaction graph. The Venmo API did not enforce access controls on transaction data, allowing researchers to scrape millions of transaction records including amounts, notes, and user identities by iterating through publicly accessible object IDs.
- Peloton user data exposure. The Peloton API exposed detailed user profile information — age, weight, city, workout history — to unauthenticated requests when querying by user ID. Even private accounts returned data.
- Parler data scraping. Before Parler's deplatforming, researchers exploited sequential post IDs in the API to download over 70TB of data including deleted posts, user metadata, and GPS coordinates embedded in media.
What Is BFLA?
Broken Function Level Authorization is related but distinct. Where BOLA is about accessing another user's object, BFLA is about calling a function you should not have access to at all. The typical pattern: your application has admin endpoints like POST /api/admin/users or DELETE /api/v1/users/{id}. These endpoints are not advertised to regular users and may not appear in your public API documentation — but they exist on the server and are callable by anyone who can discover them.
This happens because API access control is often implemented by hiding admin interfaces rather than enforcing role checks server-side. Frontend code conditionally renders admin menus based on user role. But the underlying API endpoints are open. An attacker who discovers the endpoint — through API documentation review, JavaScript bundle analysis, or directory brute-forcing — can call it as a regular user and get full admin functionality.
The core failure: BOLA and BFLA both stem from the same root cause — developers implementing authentication (who are you?) but neglecting authorization (what are you allowed to do?). Security reviews that focus on injection and XSS entirely miss this category unless they include multi-account, role-aware testing.
Why Automated Scanners Miss Them
BOLA and BFLA are fundamentally business-logic vulnerabilities. To detect BOLA, a scanner would need to: authenticate as User A, request a resource, authenticate as User B, request User A's resource, and then determine whether the response represents a valid authorization failure or a legitimate data return. That requires understanding the application's data model, maintaining multiple authenticated sessions, and reasoning about whose data should be visible to whom.
Current automated scanners — including commercial DAST tools and API fuzzing platforms — cannot do this reliably. They can detect that an ID parameter exists and fuzz it, but they cannot determine that the response represents a cross-account data leak rather than a valid response to the authenticated user.
| Vulnerability Type | Automated Scanner Detection | Manual Pentest Detection | Why the Gap |
|---|---|---|---|
| SQL Injection | High (70-85%) | Very High | Error patterns are detectable without business context |
| XSS (Reflected) | High (60-80%) | Very High | Payload reflection is a clear signal |
| BOLA / IDOR | Very Low (<10%) | High | Requires multi-account testing and business context |
| BFLA | Low (15-25%) | High | Requires role-aware testing across privilege levels |
| Business Logic Flaws | Very Low (<5%) | Medium-High | Application-specific; no generic signature |
How Pentesters Find BOLA and BFLA
In a properly scoped API penetration test, testers use a structured methodology specifically designed to surface authorization issues that scanners miss:
Multi-account testing
Testers create or obtain credentials for at least two accounts with different privilege levels — two regular users, a regular user and an admin, a free-tier user and a paid user. Every endpoint that accepts an object ID is then tested by having one account attempt to access resources created by or belonging to the other. Any successful cross-account access is a BOLA finding.
Endpoint discovery and function enumeration
API endpoints beyond what is documented are systematically discovered through JavaScript bundle analysis (which often contains API client code mapping to backend routes), reviewing the mobile application binary, analyzing network traffic during normal application use, and fuzzing common API patterns. Any endpoint accessible to a role that should not have access is a BFLA finding.
ID type variation
BOLA testing covers sequential integers (change 1001 to 1002), UUIDs (copy a UUID from one account's response and use it in another account's request), and indirect references like slugs or usernames. The presence of non-sequential IDs does not prevent BOLA — it only prevents sequential enumeration. Any ID visible to one user can potentially be used to test cross-account access.
Remediation
Fixing BOLA and BFLA requires changing how authorization is implemented, not just adding validation to existing code.
For BOLA
- Object-level authorization on every endpoint. Every endpoint that returns or modifies an object must verify that the authenticated user is authorized to access that specific object. This check must happen server-side, every time, regardless of whether the ID looks "random."
- Indirect object references where appropriate. Instead of exposing raw database IDs, use indirect references that are scoped to the authenticated user's context — ensuring that any ID a user submits maps only to objects they own.
- Centralized authorization library. Implement authorization checks as a shared function or middleware layer so individual developers cannot accidentally omit them on new endpoints.
For BFLA
- Server-side role enforcement on every endpoint. Never rely on the frontend to hide admin functionality. Every API endpoint that provides elevated capabilities must check the authenticated user's role server-side before executing.
- Deny-by-default approach. New endpoints should require explicit role grants rather than being accessible by default. A new endpoint should start with no access until roles are explicitly configured.
- Regular endpoint inventory reviews. Periodically audit all registered API routes against your intended access control matrix. Undocumented endpoints that are accessible in production are a persistent BFLA risk.
Does your API enforce authorization at the object level?
Lorikeet Security's API penetration testing uses multi-account, role-aware testing to surface BOLA, BFLA, and business logic vulnerabilities that automated tools miss. Get the assessment that actually tests what matters.
