How I Found Broken Access Control & How You Can Find It Too

Hello, and welcome back! I’m Jivan, and I’m back with another security write-up.

In this write-up, I’ll talk about a Broken Access Control vulnerability that I discovered and reported to a company.

I’ll explain how I discovered the vulnerability, how I verified its impact, and how I reported it responsibly.

But this write-up isn’t just about how I found this particular vulnerability. I’ll also explain how you can identify similar Broken Access Control vulnerabilities during your own security testing.

I hope you enjoy the write-up, and hopefully you learn something useful from it! 🚀

🎯 Run Your Bug Bounty Program with Cyberbay — Use My Referral Code

If you’re part of a company or security team planning to launch a bug bounty program, Cyberbay is a fantastic platform to consider. I’ve had a great experience working with them as a researcher, and I highly recommend their platform for managing security reports and collaborating with ethical hackers.

As a valued member of the Cyberbay community, I’m excited to share an exclusive referral code for companies: 👉 Use referral code JIVAN2025 during registration to receive 15% off your company’s first purchase on Cyberbay.

🔐 Ready to get started? Register your organization here: https://community.cyberbay.tech/signup/corporate

Whether you’re a startup or a large enterprise, launching a bug bounty program is a smart step toward strengthening your security. Don’t miss this opportunity to launch your program with a discount and the support of a growing security community!

Have questions about the process? Feel free to reach out — I’m happy to help you get started.

Now, let’s get started and see how I discovered this Broken Access Control vulnerability in [Redacted Dot Com].

For security and privacy reasons, I can’t disclose the company’s name. So, throughout this write-up, I’ll refer to the target as [Redacted Dot Com].

First, I created an account on [Redacted Dot Com] and started testing the application.

When I started exploring the application, I quickly realized that it had a lot of different functionalities and features. So, initially, I went through and tested the different functions available in the application.

During my testing, I noticed that the web application heavily used UUIDs, IDs, and other identifiers in its API requests. Since Broken Access Control and IDOR vulnerabilities often involve manipulating object identifiers, I decided to test whether these UUIDs could be replaced with identifiers belonging to another account.

I tried changing the UUIDs with identifiers associated with a different test account, but nothing worked. The application appeared to properly enforce authorization checks, and I was unable to access resources belonging to another account.

From my initial testing, it looked like the application had strong access-control protections across its API endpoints.

However, I didn’t stop there.

I continued playing around with the API requests and started testing the different endpoints individually. I carefully went through the requests generated by the application and tried different approaches to determine whether any endpoint handled authorization differently.

At this point, everything appeared to be properly secured.

Every API request I tested was correctly enforcing access controls, and I wasn’t able to find anything interesting.

But I kept testing. Sometimes, a vulnerability isn’t found by simply changing an ID — you have to understand how the application uses that ID, where it is used, and whether every related endpoint performs the same authorization check.

After some time, I came across the Developer tab in [Redacted Dot Com]. There were a few more tabs, including API Client, where I found the Broken Access Control vulnerability. You can see it in the attached screenshot.

In the API Client function of [Redacted Dot Com], I simply created a new API client from the Attacker Account, as you can see in the above screenshot. This attacker API client also has a Client ID, which is the vulnerable parameter or UUID.

After this, I switched to the Victim User account and created a new API client for the Victim User.

After this, I successfully created the Victim API Client, which contained information such as the Secret Key and Client ID, as shown in the screenshot below.

Now, I switched to the Attacker Account and captured the GET API request for the Attacker User’s API client.

GET /api/v1/privates/apiclients/{ATTACKER_CLIENT_ID}?fields=profileDetails&company=REDACTED&uid=REDACTED

This API returns the Attacker User’s API client information, including the Secret Key, creation date, API name, and other details, as shown in the screenshot below.

Then, I simply replaced the Client ID in the Attacker API request with the Victim Client ID. Then, I sent this modified Attacker API request, and it successfully returned the Victim Client’s information, including the Secret Key and other information as shown in the attached screenshot.

Does an Unguessable UUID Make the Vulnerability Invalid?

So, this is how I found this Broken Access Control vulnerability. But I know you may be confused about the Victim Client ID because, as you already noticed, this Client ID is not a numeric ID and is not directly guessable. There is also no obvious way to obtain the Victim User’s Client ID.

So, how was this vulnerability report accepted? Let me explain.

In this type of vulnerability, where the Victim ID is not guessable or there is no direct way to obtain the victim’s identifier, you can still manually copy an alphanumeric ID or UUID and test it for Broken Access Control.

This type of vulnerability can still be eligible for a bounty even when the ID is not guessable or is not directly exposed somewhere else in the application. I have reported this type of Broken Access Control vulnerability many times and received bounties for it, so it is a valid security issue to test.

I hope this clears up the confusion about how an attacker can obtain the Victim Identifier or UUID. Many new bug bounty hunters may overlook this type of vulnerability when the identifier is not predictable. However, the unpredictability of an identifier does not itself constitute an authorization control.

That said, acceptance depends on the program’s security policy and the actual attack scenario. Some companies may ask the researcher to demonstrate how an attacker could realistically obtain the UUID or identifier. If there is no realistic method of obtaining the identifier, some programs may classify the report as Informative or reject it.

In my experience, however, this type of issue has been accepted as a valid security vulnerability and has also received bounties.

Therefore, when testing Broken Access Control, you should still test whether the application properly verifies authorization, even if the ID or UUID is difficult to guess. If an attacker knows a valid identifier, the application should still prevent unauthorized access to that resource.

After all of this, once I confirmed that the [Redacted Dot Com] Client API was vulnerable to Broken Access Control, I submitted a detailed report with all the necessary explanations and proof of concept.

After that, I received a reply from the company confirming that the report had been triaged with Low severity due to the attack complexity.

A few months later, the company deployed a fix and requested a retest. I retested the vulnerability, and it was no longer reproducible because the application was now properly verifying ownership of the Client API.

So, this is how I found and reported this Broken Access Control vulnerability. You can also use a similar approach when testing for Broken Access Control vulnerabilities during bug bounty hunting.

🙏 Thank for reading this case study

This write-up was meant to share my practical experience of finding and validating a Broken Access Control vulnerability in an API.

The key takeaways are:

• Understand how the application’s API endpoints and authorization controls work.
• Do not assume that an unguessable UUID or ID makes a resource secure.
• Test whether the application properly verifies resource ownership and authorization.
• Carefully analyze the actual impact of unauthorized data access.
• Clearly document your findings with proper steps to reproduce and evidence.
• Always perform testing within the scope and rules of the bug bounty program.

I hope this write-up helps other security researchers better understand how to approach Broken Access Control testing, especially when applications use random or unguessable UUIDs.

Keep learning, keep testing, and always practice responsible security research. 🔐