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.
SOCIAL SHARE CARD GENERATOR