API1:2023 Broken Object Level Authorization
APIs are at the core of modern software architectures. With the rise of microservices, mobile applications, and third-party integrations, APIs have evolved from simple data access layers into critical components that directly manage business processes. User profiles, orders, invoices, accounts, and similar business objects are accessed and managed through APIs.
However, one of the most common mistakes in such architectures is the assumption that authentication alone is sufficient for security. In reality, the primary risk in API security lies not in who the user is, but in which objects the user is allowed to access. Ranked first in the OWASP API Top 10:2023 list, API1: Broken Object Level Authorization (BOLA) emerges precisely at this point.
What Is Broken Object Level Authorization?
Broken Object Level Authorization occurs when an API processes object identifiers received from a client (such as IDs, UUIDs, or keys) without verifying whether the requested object actually belongs to the authenticated user. In other words, the system verifies who the requester is, but fails to check whether that user is authorized to access the specific object being requested. This flaw allows an authenticated user to gain access to other users’ data simply by modifying an object identifier value.
BOLA is considered a silent vulnerability. It often does not trigger errors, appears as a legitimate request in logs, and can lead to data leakage over long periods without being detected. One of the main reasons BOLA is so widespread is the frequent confusion between authentication and authorization in practice. In many systems, once a user is authenticated, it is assumed that access to a given endpoint is sufficient. However, in APIs, authorization must be enforced not only at the endpoint level but also at the object level. Being authorized to call an endpoint does not imply ownership of the object being accessed.
Even when endpoint-level access control is correctly implemented, Broken Object Level Authorization arises if object ownership checks are missing. For this reason, BOLA is often overlooked during code reviews and security testing, despite its potentially severe impact.
Common BOLA Scenarios and Their Impact
Broken Object Level Authorization typically stems from predictable and repetitive architectural flaws. In APIs that rely on incremental numeric identifiers, endpoints such as /api/users/1001 or /api/orders/45891 become natural targets for attackers. If the backend does not verify whether the requested object belongs to the authenticated user, an attacker can access other users’ data by simply changing the identifier.
Another common mistake is trusting object ownership information provided by the client. Accepting fields such as userId from the request body without server-side validation creates a classic entry point for BOLA. Similarly, the assumption that “this ID is not visible in the UI” is a frequent misconception. APIs operate independently of user interfaces; attackers interact directly with the API, and UI-level restrictions do not provide security.
BOLA is not merely a technical vulnerability but a direct business risk. Unauthorized data access can lead to the exposure of personal data subject to regulations such as GDPR. Additionally, attackers may perform unauthorized update or deletion operations on behalf of other users. Due to its silent nature, BOLA-related breaches are often detected late, amplifying regulatory consequences and reputational damage.
To minimize BOLA risk, object-level authorization must be treated as a fundamental design principle in API architectures. For every data access operation, the system must verify that the accessed object belongs to the authenticated user. These checks should be implemented centrally at the service or domain layer rather than being scattered across controllers. A deny-by-default approach should be adopted, where access is explicitly granted and otherwise rejected.
Furthermore, object-level access should be logged, and sequential or anomalous identifier access attempts by the same user should be evaluated as potential anomalies. Controls implemented only during development or testing are not sufficient; runtime behavioral analysis plays a critical role in detecting such abuse patterns. Modern API security solutions can analyze API traffic to detect and surface object-level authorization violations in real time.
API1:2023 Broken Object Level Authorization is one of the most fundamental yet most destructive security flaws in API security. Being authenticated alone is not sufficient to access a resource. The defining question in API security is not “Who is logged in?” but rather “What is this user allowed to view, modify, or control?” Therefore, every API should be designed around a holistic security approach that places object-level authorization at its core and continuously monitors these controls at runtime, not only during design or testing phases.
