Broken Object Level Authorization (BOLA), also known as Insecure Direct Object Reference (IDOR), is the most critical API security vulnerability. It occurs when an API endpoint receives an object identifier (ID) and performs actions on that object without properly validating whether the requesting user has permission to access it.

Broken Authentication occurs when API authentication mechanisms are poorly implemented, allowing attackers to compromise authentication tokens, passwords, session IDs, or exploit implementation flaws to assume other users' identities temporarily or permanently.

Broken Object Property Level Authorization occurs when an API exposes too many object properties or allows users to modify properties they shouldn't have access to. This vulnerability manifests in two primary forms:

Unrestricted Resource Consumption occurs when an API fails to properly limit the consumption of computational resources, network bandwidth, storage, or other system resources. This allows attackers to overwhelm the API through legitimate requests, leading to Denial of Service (DoS), performance degradation, or excessive operational costs.

Broken Function Level Authorization (BFLA) occurs when an API endpoint does not properly verify whether the authenticated user has the necessary privileges to execute a specific function. Unlike object-level authorization (which controls access to specific data), function-level authorization controls access to specific operations or capabilities.

Unrestricted Access to Sensitive Business Flows occurs when APIs fail to detect and prevent automated or excessive use of critical business functionality. Unlike traditional rate limiting that focuses on preventing service degradation, this vulnerability centers on protecting business logic from abuse by automated tools, bots, and scripts.

Server Side Request Forgery (SSRF) occurs when an API fetches a remote resource without validating the user-supplied URL. Attackers can exploit this to access internal systems, cloud metadata services, or perform port scanning and network mapping from the server's perspective.

Security Misconfiguration occurs when any part of the API stack is deployed with insecure settings: options left at insecure defaults, security controls that were never enabled, permissions that are too broad, or verbose behaviour that leaks internal detail. It is not a single bug in your code—it is the accumulated gap between how software can be hardened and how it was actually shipped.

Improper Inventory Management is the API security risk that arises when an organization loses track of where its APIs are, what versions are running, and what data each one exposes. It is less about a single flawed line of code and more about an organizational blind spot: hosts, endpoints, and versions that exist, answer requests, and touch real data, but that nobody is actively cataloguing, patching, or monitoring.

Unsafe Consumption of APIs occurs when an application blindly trusts data received from third-party or upstream APIs and processes it without the same validation, sanitization, and transport controls it applies to direct user input. Developers instinctively trust data returned by a partner API, an identity provider, a payment processor, or an internal microservice far more than data typed by an end user — and that misplaced trust is exactly what makes the integration a soft target.