It Started With a Simple Request

While exploring a state government web application, I came across a feature where users could apply for a service and upload supporting documents.
Pretty standard flow:

• Submit application
• Upload ID proof
• Upload address proof

Later, users could retrieve their documents through the portal.

Nothing unusual… until I looked at the request behind it.

The API That Did Too Much

The application fetched documents using a request like:

/api/getDocument?id=10234

At first, it worked as expected — I could access my own uploaded documents.
But something felt off.

The id parameter looked:

• Numeric
• Sequential
• Predictable

And from experience, that’s always worth testing.

The One Change

Out of curiosity, I modified the request:

/api/getDocument?id=10235

Sent it.

And waited.

What I Saw Next Was Alarming

The server responded successfully.

But the document wasn’t mine.

It belonged to someone else.

And It Got Worse

I tested a few more IDs (carefully, without abusing the system).

Each time, I could access documents uploaded by different users.

These weren’t just random files.

They included:

• Government-issued ID proofs
• Address verification documents
• Supporting files submitted for official services

Highly sensitive. Personally identifiable. Real.

The Real Problem

At this point, the issue was clear:

The application had no proper authorization checks.

It didn’t verify:

• Who was making the request
• Whether the document belonged to that user

Instead, it followed a dangerous logic:

“If the ID exists, return the file.”

The Vulnerability: IDOR

This is a classic case of Insecure Direct Object Reference (IDOR).

Where:

• Internal object IDs are exposed
• Access control is missing
• Attackers can retrieve unauthorized data

Why This Was Serious

This wasn’t just a minor bug.

The impact included:

• Exposure of sensitive identity documents
• Risk of identity theft and fraud
• Potential for mass data scraping
• Violation of citizen privacy

And the scary part?

👉 No advanced skills required
👉 No authentication bypass needed
👉 Just changing a number

Responsible Disclosure

Once I confirmed the issue:

• I documented a clear Proof of Concept
• Included reproducible steps
• Highlighted the severity and real-world impact

The issue was responsibly reported to the concerned authority.

It was acknowledged and fixed.

Recognition

As a result of this report:

• The vulnerability was patched
• I was recognized by CERT-In Hall of Fame

Key Takeaway

This experience reinforced a powerful lesson:

The most dangerous vulnerabilities are often the simplest.

One parameter.
One small change.
Huge impact.

Final Thoughts

If you’re into security or bug hunting:

• Always inspect API requests
• Never trust exposed IDs
• Follow your curiosity

Because sometimes…

Changing one number is all it takes.