> For the complete documentation index, see [llms.txt](https://x7331.gitbook.io/notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://x7331.gitbook.io/notes/apisec/api-testing/exploiting-api-authorization/bola.md). # BOLA **Broken Object Level Authorization (BOLA)** occurs when authorization controls are lacking or missing, `UserA` will be able to request `UserB’s` resources. APIs use values, such as names or numbers, to identify various objects. When we discover these object IDs, we should test to see if we can interact with the resources of other users when unauthenticated or authenticated as a different user. The first step toward exploiting BOLA is to seek out the requests that are the most likely candidates for authorization weaknesses. When hunting for BOLA there are three ingredients needed for successful exploitation. 1. **Resource ID**: a resource identifier will be the value used to specify a unique resource. This could be as simple as a number, but will often be more complicated. 2. **Requests that access resources**. In order to test if you can access another user's resource, you will need to know the requests that are necessary to obtain resources that your account should not be authorized to access. 3. **Missing or flawed access controls**. In order to exploit this weakness, the API provider must not have access controls in place. This may seem obvious, but just because resource IDs are predictable, does not mean there is an authorization vulnerability present. > *The third item on the list is something that must be tested, while the first two are things that we can seek out in API documentation and within a collection of requests.*
Check the requests 1 by 1 for potential vulnerable endpoints that expose a pattern, e.g. an ID, either in the URL or the request body. ## Authorization Testing Strategies ### A-B Testing 1. Create a user account (`UserA`). 2. Use the API and discover requests that involve resource IDs as `UserA`. 3. Document requests that include resource IDs and should require authorization. 4. Create another user account (`UserB`). 5. Obtain a valid `UserB` token and attempt to access `UserA`'s resources. Make successful requests as `UserA` with `TokenA` and then change to `TokenB` and try the same requests to `UserA`'s resources.