Automating BOLA Discovery: How LLMs Are Changing API Security Testing

TLDR: Broken Object Level Authorization (BOLA) remains the most critical risk in modern APIs, yet manual testing at scale is notoriously difficult. Researchers have developed BOLABuster, a tool that uses LLMs to parse OpenAPI specs, map complex dependency trees, and generate targeted bash scripts to identify BOLA flaws. This approach successfully uncovered 17 critical vulnerabilities in major open-source projects like Harbor and Grafana.

API security testing is often a game of cat and mouse where the mouse has a massive head start. While tools like RESTler have made strides in automated fuzzing, they often struggle with the logical complexity inherent in OWASP API1:2023 Broken Object Level Authorization. BOLA is not a syntax error or a malformed packet; it is a failure of the backend to verify that the user requesting an object actually has the right to access it. Because this is a logical flaw, traditional scanners frequently miss it or generate an overwhelming amount of noise.

The Logic Gap in Automated Fuzzing

Most automated fuzzers treat API endpoints as isolated units. They see a GET /api/v1/user/123 and a DELETE /api/v1/user/456 and test them independently. However, real-world BOLA vulnerabilities are often hidden behind stateful dependencies. You cannot test the deletion of a comment without first creating an article, then creating a comment on that article, and finally attempting to delete it with a different user's token.

This is where the research presented at DEF CON 2024 shines. Instead of brute-forcing endpoints, the researchers used LLMs to act as a bridge between the static OpenAPI specification and the dynamic execution flow. By feeding the API spec into an LLM, the tool identifies "potentially vulnerable endpoints" (PVEs) that handle sensitive data. It then maps the dependency relationships—identifying which endpoints act as "producers" (creating resources) and which act as "consumers" (accessing or modifying them).

From Dependency Trees to Executable Payloads

The core innovation here is the transformation of these dependency trees into executable bash scripts. The tool constructs a path from a leaf node (the creation of a resource) to the root node (the target endpoint). It then generates a script that performs the necessary authentication, resource creation, and finally, the unauthorized access attempt.

Consider a scenario where you want to test if a user can delete another user's comment. The generated script follows this logic:

# High-level logic for a BOLA test script
# 1. Authenticate as User A (Producer)
# 2. Create an article
# 3. Create a comment on that article
# 4. Save the comment ID
# 5. Authenticate as User B (Attacker)
# 6. Attempt to DELETE /api/comments/{comment_id}

By automating this sequence, the tool ensures that the test is not failing due to a 404 or a missing dependency, but rather because of an actual authorization failure. If the DELETE request returns a 200 OK when executed by User B, you have a confirmed BOLA.

Real-World Impact and Findings

The effectiveness of this methodology was proven by the discovery of 17 new BOLA vulnerabilities in widely used open-source software. The findings in Harbor are particularly instructive. The researchers found that an unauthorized user could modify project configuration metadata, effectively allowing a low-privileged user to escalate their access to administrative levels. This is a classic example of how BOLA can lead to full application compromise, far beyond simple data leakage.

For a pentester, this tool changes the engagement workflow. Instead of spending hours manually mapping out API flows in Burp Suite to find the right sequence of requests, you can feed the OpenAPI spec into the tool and let it generate the test suite. This allows you to focus your manual effort on the complex, non-standard endpoints that the LLM might struggle to parse.

Defensive Considerations

Defenders must recognize that BOLA cannot be solved by a Web Application Firewall (WAF) alone. Because the request is syntactically correct and the user is authenticated, the WAF sees a legitimate request. The fix must happen at the controller level in the application code. Every time an object is accessed, the backend must verify that the user_id associated with the session has an explicit permission relationship with the object_id being requested.

If you are building APIs, stop relying on implicit trust. Implement object-level authorization checks in your middleware. If you are a researcher, start integrating these LLM-assisted workflows into your reconnaissance phase. The goal is not to replace manual testing, but to offload the tedious, repetitive task of dependency mapping to a machine that can do it in seconds. The next time you are staring at a massive API documentation file, remember that the logic flaws are likely hidden in the relationships between those endpoints, not in the endpoints themselves.