I Changed One Number… and Got Access to Citizens’ ID and Address Proofs

Suraj Kumar H M — Mon, 01 Jun 2026 08:10:05 +0000

How a simple parameter manipulation exposed highly sensitive government records

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.

• Portfolio: https://surajkumarhm.vercel.app
• ORCID Research Profile: https://orcid.org/0009-0004-2990-8300
• LinkedIn: https://www.linkedin.com/in/surajkumarhm

Let's connect and contribute to a safer and more secure digital ecosystem.

DEV Community: Suraj Kumar H M