Finally, the day arrived when I could share my own findings, rather than just reading other researchers’ findings (which I truly love to do, as they are a significant source of my motivation). Without further ado, let’s dive into the journey of my first bug discovery. In short, it’s an API misconfiguration bug where I found an API key with potentially dangerous permissions in the request.

Allow me to introduce you to our target with a cliché statement: let’s call it “example.com,” an e-commerce website.
For a couple of days, I tried to find various vulnerabilities like login bypass, XSS, subdomain takeover, and more, but my efforts were in vain and no good came out of it. Just as my beginner’s patience was wearing thin, I stumbled upon a Medium blog post of a researcher where he found some sensitive data in JavaScript files. Inspired, I decided to try it on my target and started hunting for JS files.

The command I used was
echo “example.com” | gau | grep .js | httpx -mc 200

This led me to discover a ton of JS files. After spending some time, I came across one suspicious file. I copied the JS file data in my VS Code to make it easily readable. I dug into it and found some intriguing data.

It contained many secrets and API keys, but as a beginner, I had no idea how to leverage this information. And then I turned to every bug hunter’s friend: RESEARCH!!. I just sat and started searching on Google, ChatGPT, Github repositories, read some blogs, consulted some mentor-friends, all in an attempt to exploit this sensitive data. Regrettably, my efforts yielded little success as the API keys and secrets I had discovered were either not exploitable, like the ALGOLIA key for the blog site, which had permissions of recommendation and search only,

and others led to publicly accessible data, such as the content of the target’s blog site hosted on “contentful.com.” Another dead end.

I was on the brink of abandoning this target for the second time when I decided to glance through my target list in Burp Suite, searching for something interesting — a tip I’d read about in another blog. And that’s when it happened.

A host caught my eye:
https://(application_id).algolianet.com

As I inspected the requests made to this host, I noticed something intriguing. Some requests used the same API key I had found in the JS file, while others contained a different API key.

This difference caught my attention, and I went back to this blog that I had read earlier:

https://www.secjuice.com/api-misconfiguration-data-breach/

Using this knowledge, I explored the permissions of this new API key.And that’s when I had my Eureka moment.

It had permissions to add and delete objects. I didn’t try to add or delete something, fearing I might break the site. I knew that these were some dangerous permissions. So I prepared a report and submitted it. Within a day, it was triaged as high severity, but after a few days, it was updated to critical.

My patience had paid off, with a touch of luck, I might add. It is not a technical bug like XSS with some crazy payload or something, but a bug’s a bug, and this one can bring a whole blog site down!!!!

Special thanks to Debarghya Sahoo and Aditya Shende.