How I Discovered a PII Leak in a Developer Platform
Introduction
In this article, I walk through a bug I reported through a bug bounty program. The issue was Excessive Data Exposure (OWASP API Top 10 - API3:2019), where an API endpoint exposed users’ email addresses, including internal employees’ when accessing profiles. I explain how I found the bug, including the steps and tools I used, so readers can better understand how to identify similar vulnerabilities in their own bug bounty research.
Target Discovery and Analysis
After picking a target, I started by enumerating all the related subdomains and exploring them manually in the browser. I focused on ones that seemed interesting, basically, any subdomain with some functionality. That’s when I found developer.redacted.com, which was a forum-like platform where users could post, reply, and follow others, kind of like a mini social media site. I created an account and started clicking around, watching requests in Burp Suite. I noticed IDs being passed, so I tried some IDOR testing in different places, but nothing worked. I also checked for other common vulnerabilities, like “Forgot Password” issues or XSS, but those didn’t yield anything either.
Also, if you’re interested in IDOR bugs, check out my below article :)
Finding the Bug
Later, while inspecting the response in Burp Suite, I noticed that the JSON body contained a lot of information about the user. Most of it seemed normal, profile details, usernames, and other non-sensitive fields, but one field immediately stood out: the email address of the user. This was alarming because the email of the different user was exposed.
While following a user, a PUT request was sent to the server. I captured this request and sent it to the Repeater in Burp Suite. That’s when I saw the email address of the user I was following, including the email address of the user who had followed that particular person. This is an obvious PII leak, as sensitive personal information was being exposed through normal forum interactions.
Interestingly, I noticed that other endpoints returned similar JSON responses, but in those cases, the email was encrypted. This particular endpoint, however, exposed the email in plain text, seemingly the developer forgot to encrypt it. Regardless, this was an Excessive Data Exposure bug and falls under the OWASP API Top 10 category.
Reporting the Bug
Finally, I decided to report the bug on HackerOne. I included multiple screenshots in the report, including one showing the email address of an internal company employee, which even included their company domain (e.g., abc@company.com) I always make sure my reports are detailed and thorough. Once the report was submitted, I waited for a response from the program.
It took a few weeks for the team to reply, but eventually the report was triaged. Since this was a vulnerability disclosure program, I didn’t receive a bounty, but I did earn points for the submission so its good and ofcourse a learning experience too.
Oh, I also created a video on this topic a while back. If you’re interested in how to approach finding this bug, check it out!
Final Thoughts
This bug hunt was a reminder that sensitive data can slip through even normal functionality. For bug bounty hunters, careful recon and inspecting API responses is key. While this was a disclosure program without a monetary reward, it was still satisfying to see the bug triaged and earn points for the submission. See you next time!
Follow me on X for more updates: https://x.com/medusa_0xf
