When you spend enough time in bug bounty hunting, you realize something important: the best findings rarely come from doing the same thing as everyone else.

This is the story of how I discovered an IDOR vulnerability exposing billing addresses and email information with other bug(which later I'll be chained it) in a BugCrowd Public Program.

Starting With a Public BugCrowd Program

Like many hunters, I was browsing BugCrowd looking for a program to work on. Eventually, I selected a public program from a company that we will call it as BUGVECTOR.COM.

Public programs are interesting but also challenging.

Why?

Because thousands of hunters have probably already tested the same targets. That means the obvious vulnerabilities are usually gone.

But I still gave it a shot with a little bit different approach.

A Familiar Technology Stack

While exploring the program scope, I found a web application using an older web technology stack — the kind that often exposes its file extensions directly in URLs.

For many people, that might not mean much.

BUT For me? It was totally different. 😙

I was very familiar with this type of technology, which meant I already understood many of its typical implementation mistakes and architectural patterns.

So I started my usual process:

• Reconnaissance
• Fingerprinting the web application
• Mapping endpoints
• Testing common vulnerabilities

I tested things like:

• SQL Injection
• Account Takeover possibilities
• Authentication flaws
• Input validation issues

But nothing worked.

At this point I started thinking realistically.

This was a public Bugcrowd program, meaning the web app had probably already been tested by thousands, maybe millions of requests from other hunters.

The chances of finding something obvious were low. 😔

My Bug Hunting Philosophy

From the beginning of my journey in bug bounty, I've always had one rule:

Aim for high-impact vulnerabilities.

I'm not a big fan of spending hours crafting complicated payloads for things like:

• Low-impact XSS
• HTML injection
• Minor UI bugs

Sometimes I test them quickly (like uploading SVG payloads), but honestly…

I'm too lazy to craft complicated exploit chains for low impact bugs. 😅

So instead, I try to focus on vulnerabilities that can cause serious impact.👽

And because of that GOAL requires thinking differently from the average hunter.

Changing the Strategy

Most hunters usually focus heavily on:

• Recon
• Directory bruteforce
• Endpoint discovery
• Parameter fuzzing

But if everyone is doing the same thing…

Your chances of discovering something new become smaller.

So I decided to try a different approach.

Instead of attacking the main domain, I began investigating other subdomains that might interact with the same backend systems. Even in the guidelines already stated it's a 50:50 situation either it will be accepted or not.

Large organizations often run multiple applications connected to the same database or authentication system.

If the integration is weak, it can create interesting attack surfaces. 👽

Discovering the Subdomain

While enumerating subdomains, I found one we will call:

subdomain.bugvector.com

The first thing I did was simple.

I tried logging in using the same credentials I had created on the primary domain.

And surprisingly…

It worked.

Successfully.

That immediately told me something important.

Both applications were using the same backend database for authentication. 😉

This is where things usually get interesting.

Starting With the "Double-A" Approach

My first testing methodology is what I call Double-A:

• Authentication
• Authorization

So I started checking things like:

• Login flows
• Password reset
• Registration
• Account Profile

Everything looked fairly secure at first.

But eventually, I discovered a smaller issue.

The First Finding: Email Uniqueness Bypass

I found that the application did not properly enforce email uniqueness during update profile. This also affected their primary domain since they use the SAME DATABASE. 😙

This meant:

Multiple accounts could use the same email address.

However, the behavior was strange.

If multiple accounts shared the same email:

• The latest account that updated its profile would control the password reset functionality.
• Other accounts using the same email could no longer reset their password.

This created an Account Recovery Disruption vulnerability.

Technically it was a valid bug. 😋

But honestly…

It didn't satisfy me.

Even if I reported it, BugCrowd would at least classify as P5 — INFORMATIONAL

I wanted something bigger. 😁

Exploring the Checkout Function

While exploring the application further, I eventually reached the checkout page.

That's when things started getting interesting.

I noticed a POST request being sent when initiating the checkout process.

The request looked something like this:

This request appeared to do 3 important things:

1. Generate a payment token.
2. Load billing information from `student_id` parameter.
3. Load product information from `sku` parameter

The payment processing was handled by Authorize.Net, a common merchant gateway.

Whenever payment systems are involved, it's always worth taking a closer look.

The Suspicious Parameter

The parameter that caught my attention immediately was:

student_id

Whenever I see identifiers like:

• user_id
• account_id
• student_id
• order_id

My brain immediately asks one question:

Is this vulnerable to IDOR or maybe SQL injection?

So I began testing. 😆

The IDOR Test

I created a second account and noted its student ID value.

Then I modified the request.

Instead of using my original account's ID, I replaced the parameter with the ID of my second account.

Something like:

student_id=123463

Then I sent the request.

And suddenly…

The page redirected me to the Authorize.Net merchant page.

But that wasn't the shocking part.

The billing information was already filled in.

Including:

• Billing address
• Email address
• Other payment related data

But it did not belong to the account currently logged in!

It belonged to the student_id I had supplied. 😙

The Realization

At that moment, I realized what was happening.

The application was:

• Trusting the student_id parameter from the client
• Without verifying if the user was authorized to access that record

Even worse:

The IDs were sequential.

Which meant an attacker could potentially iterate through them and retrieve billing information for many users.

That's a classic Insecure Direct Object Reference (IDOR).

And due to the exposed billing information and email addresses, the impact was significant.

The Luckiest Moment

When I confirmed the vulnerability, I remember thinking:

I might be the luckiest person alive today.

Not because it was easy.

But because changing the strategy paid off.

Instead of competing with thousands of hunters on the main application, the vulnerability was hiding in a less-tested subdomain integration.

Reporting the Vulnerability

Without wasting time, I immediately started preparing the report and submit it. And for the last moment, I received $$$ payout.

Later I write another report about chained method that led to Account Recovery Disruption due to lack of email uniqueness enforcement. The status is waiting for the customer to respond since this report is also about IDOR which is the root cause that will lead to the vulnerability.

Final Thoughts

Bug bounty hunting isn't just about tools or payloads.

It's about thinking differently.

Sometimes the difference between finding nothing and discovering a high-impact vulnerability is simply asking:

What if I try a different path?

And in this case, that path led directly to an IDOR exposing sensitive billing information with email bypass uniqueness.

Thanks for reading!

Connect me:

X: https://x.com/wanahmadqais007