Why BOLA’s "authorization gap" requires a runtime strategy

Chaim PeerSenior Product Manager | F5

Ian DinnoSr. Product Marketing Manager | F5

When it comes to broken object-level authorization (BOLA)—one of the OWASP API Security Top 10 vulnerabilities—shifting left is an incomplete strategy. BOLA is not a simple coding error, such as a typo; it is a fundamental failure in business logic.

Relying on developers to manually check every single ownership rule in a sprawling microservices environment is a high-stakes gamble. In 2026, with strict U.S. Securities and Exchange Commission (SEC) disclosure rules and aggressive General Data Protection Regulation (GDPR) enforcement, a “logic bug” can quickly become a material financial disaster.

The anatomy of the authorization gap

In the monolithic era, authorization was implicit. The server held the session in its own memory, knew exactly who was logged in, and controlled the database query in one single, centralized process.

Modern cloud architectures have shattered this model. Today, we separate identity (managed by external providers) from the data (residing in hundreds of discrete services). We verify who the user is at the front door, but we often leave the verification for what they own or can access to the backend developer.

The “authorization gap” is the space between a successful login and a missing ownership check. Because modern services are stateless, they inherently trust the requests they receive. If a request includes “Order 7788” and the code does not explicitly verify that the order belongs to the requester, the data is stolen.

Visualizing the authorization gap

To understand why relying solely on a web application firewall (WAF) is insufficient to protect against BOLA vulnerabilities, we must look at the technical disconnect between authentication and resource ownership in modern, stateless APIs. WAFs look for “bad” syntax, such as SQL injection, but BOLA exploits use “good” syntax that appears to be a normal request. To stop BOLA, your defense must become identity-aware, validating the user against the specific object they are requesting.

Consider a banking application. An attacker, User A, logs into their own account (User ID: 8899) and receives a valid session token. This user is now authenticated, and the attacker can attempt to access the data of someone else, User B, by sending a request to /api/v1/accounts/1234/balance.

The WAF checks for SQL injection or malicious scripts. Since 1234 is a perfectly valid integer and the syntax is clean, the WAF passes the request through.

The API gateway verifies that the session token is valid and hasn't expired. Because User A, the attacker, is a legitimate, logged-in user, the gateway marks the request as authenticated and forwards it to internal systems in the backend.

As a result, the backend service receives the “trusted” request and returns the balance for account 1234. The attacker has successfully bypassed security because the gateway confirmed who they were, but never checked what they were allowed to access.

The “before” scenario: a broken trust model

In many modern architectures, the API gateway acts as a “bouncer” who only checks IDs at the door. Once a user provides a valid JWT or session cookie, the gateway assumes every subsequent request from that user is legitimate.

User A logs in and receives a valid token. They then send a request to GET/api/v1/data/1234. The next step in this process is the syntax and session check, where the standard WAF confirms the request is clean (no SQL injection) and the API gateway confirms the session is valid.

Here is where the authentication gap occurs: neither the WAF nor the gateway checks if resource 1234 actually belongs to User A, and the backend service blindly trusts the “verified” request from the gateway and serves the private data of User B to User A. This is where the breach happens.

However, with an advanced API security solution, this new bouncer doesn't just check the user’s ID at the door; it verifies that the user is authorized to enter every specific room that the user tries to walk into.

The “after” scenario: identify-aware enforcement

Here are the steps that advanced API security solutions take to close the authentication gap and validate that the logged-in user has permission to perform the requested action on the requested object.

In the first step, the system extracts the identity (User A) from the token and the resource ID (1234) from the request. Then, using a learned Business Logic Map, the platform identifies that resource 1234 is owned by User B, not User A.

In the third step, because the identity-to-resource mapping fails the logic check, the request is dropped at the application’s edge, before it is allowed to interact with internal systems. In the end, the unauthorized request never reaches the application’s backend, where data is stored, preventing data exfiltration before it starts.

Why shift left fails to stop BOLA

Moving security checks and testing to earlier stages in the development lifecycle cannot alone solve this problem because shift left tactics lack context. Tools like static analysis (SAST) look at the code, not the data, so they don’t know that User A is not authorized to see User B's invoice because that relationship is defined in the database, not the source code.

In addition, most dynamic analysis (DAST) tools only scan within a single user’s context. They see a “200 OK” response and mark it as a pass, unaware that the user is accessing another user's private records.

Conversely, standard API testing is context-blind. In essence, it’s like testing in a vacuum. It fails because it ignores real-world traffic data. If your tests can't see how Identity A maps to Resource B in production, they can only validate syntax, not logic. You aren't testing your business.

Enforcement at the edge

To fix this problem, organizations need a three-layered runtime strategy that consists of:

1. User-to-resource mapping. The API security solution extracts the identity from the token and compares it to the resource ID in the HTTP request message (header, cookie, path, or body).
2. An Open Policy Agent (OPA) sidecar. Instead of trusting hundreds of developers to write unique checks, use OPA to manage authorization rules in one central place. An OPA sidecar is a deployment pattern that runs alongside an application container to provide low-latency, high-performance local authorization decisions, allowing policies to be evaluated in real time for microservices and API security.
3. Behavioral monitoring. To stop BOLA attacks, your defense must extract the identity (who), context (how), and resource (what) from live traffic to build a baseline of normal relationships. For example, if a single user deviates from an established baseline, such as attempting to access 50 different IDs in one minute, the system identifies this anomaly. This is a clear signature of a scraper, not a human, and must be blocked immediately.

How F5 helps

F5 Distributed Cloud API Security provides a clear pathway from zero visibility to enforced runtime protection. As part of F5 Distributed Cloud Services, it provides unified security, combining app delivery and security into one platform. By correlating intelligence across components like distributed denial-of-service (DDoS) mitigation, anti-bot, API security, and WAF, it distinguishes between a single customer’s request and coordinated, multi-vector attacks by leveraging automation.

The product’s API discovery feature automatically finds all APIs, including “shadow APIs,” and continuously analyzes production traffic to learn your application's actual business logic and map how users interact with specific data objects. Context-aware testing uses these insights to run targeted “matrix testing” in pre-production environments, identifying weak points in identity-to-object mappings before code deployment.

Distributed Cloud API Security also provides BOLA attack detection, identifying various BOLA scenarios by correlating learned behavioral baselines with incoming requests to detect suspicious activity, which can inform runtime protections.

In 2026, BOLA attacks are some of the fastest ways to suffer a data breach. Shifting left is good for finding technical bugs, but “staying right” is the only way to fix broken business logic. Move your authorization to the edge and stop the data leak now.

Learn how F5 can help organizations protect their APIs, or see it in action.

About the Authors

Chaim PeerSenior Product Manager | F5

More blogs by Chaim Peer

Ian DinnoSr. Product Marketing Manager | F5

More blogs by Ian Dinno