Every bug hunter knows the feeling. You're staring at your screen at 2:00 AM, eyes burning, looking at a JSON response that seems… too good. You ask yourself: Is this a real vulnerability, or am I just looking at public data?

When I first started in bug bounty, I was plagued by imposter syndrome. I had submitted reports in the past where I thought I had found sensitive data, only to be hit with the dreaded "Informative" or "N/A" status with a note saying, "This is meant to be public."

The hesitation!!

So, when I first stumbled upon an endpoint leaking employee data — full names, emails, roles, and IDs — I hesitated. It felt too easy. To find Personally Identifiable Information (PII) sitting right there on a silver platter felt like a trap. I convinced myself it was probably public directory information. I closed my laptop and went to sleep.

That decision taught me the greatest lesson of my bug bounty career.

The Sinking Feeling (And the Confidence Boost)

The next morning, I poured my coffee, opened my laptop, and refreshed the endpoint just to check.

404 Not Found

My stomach dropped. The endpoint was gone. Someone else had found it, reported it, and the security team had patched it while I was sleeping.

For a split second, I wanted to quit. I had a valid bug sitting right in front of me, and I let it slip away. But then, a completely different realization washed over me: I actually found a real bug.

Until that morning, I wasn't sure if I was truly capable of finding vulnerabilities on public targets. But seeing that 404 error was the ultimate validation. It proved my instincts were right. The hesitation was gone. I knew for a fact that this type of information was not meant to be public, and I knew exactly what to look for next.

The Methodology: Digging Deeper

I didn't have to start from scratch. My methodology was already sound. I had already performed comprehensive reconnaissance, running subfinder to enumerate subdomains and piping those into httpx-toolkit to identify live targets. I had already run katana to spider those targets, which had surfaced a Swagger UI endpoint I'd previously ignored.

I went back to the Swagger documentation. I didn't just look for /users or /admin this time; I systematically audited every single endpoint listed in that UI.

That's when I hit /opa/data.

The "Aha!" Moment

When I sent a GET request to /opa/data, the server didn't respond with JSON. Instead, my browser downloaded an archive: a.tar.gz.

My hands were shaking as I unpacked the archive. Inside, I found the holy grail of Open Policy Agent (OPA) configurations. Because I had missed the first bug, I immediately recognized the structure of the data. I wasn't just looking at a list of users; I was looking at the entire authorization brain of the application.

The archive contained the core OPA logic files (uam_policy.rego and user_permissions.rego), alongside the exact JSON mappings the system used to determine who gets access to what:

  • user_group/data.json → Mapped real employee email addresses, full names, and employee numbers to specific internal authorization groups.
  • group_role/data.json → Defined the exact roles assigned to each of those groups.
  • role_policy/data.json → Associated the roles with internal access policies.
  • policy_permission/data.json → Mapped the policies directly to specific, sensitive resource permissions.

This wasn't just a data leak; it was a complete blueprint of their internal access control architecture, paired with the PII of their employees.

The Takeaway

I immediately wrote up the report, prioritizing the business impact. Because I understood exactly why this data was sensitive — thanks to my failure the night before — I was able to articulate the exact risk this posed to the company. It was triaged and validated as a medium-severity employee data leak, officially marking my very first successful bug bounty win.

If there is one thing you take away from this writeup, let it be this: Trust your gut.

If you find an endpoint dumping data and your imposter syndrome tells you "it's too easy, it must be public," report it anyway. Let the triager tell you it's N/A. Don't self-triage your bugs out of fear of rejection.

Sometimes, the bug you sleep on is the exact lesson you need to find the bug that pays.

Tools Used in this Hunt:

  • Subfinder/Httpx/Katana: For disciplined, automated discovery of the Swagger UI entry point.
  • Burp Suite Professional: For manual endpoint testing and traffic interception.
  • Open Policy Agent (OPA): Understanding .rego files was key to articulating the severity of the authorization leak.

I hope you liked this writeup, may be learned something from it. This is my first ever writeup, please let me know if you liked this writeup.

BYE !!!

My socials:

linkedin — https://www.linkedin.com/in/hamja-bohra-012952156/

instagram — https://www.instagram.com/hamzaburhanuddin2