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.