The Vulnerability Nobody Scans For: Understanding IDOR and Why It Keeps Appearing in Indian Web Platforms
The Vulnerability Nobody Scans For
May 27, 2026
There is a category of web application vulnerability that automated security scanners almost never catch, that WAFs cannot block, that penetration testing tools routinely miss — and that keeps appearing in production systems handling sensitive data across India.
It is called Insecure Direct Object Reference. IDOR, for short. And it is, in my view, the most consequential class of vulnerability in Indian web infrastructure today.
What IDOR Actually Is
Every database-backed web application stores records — user profiles, orders, documents, medical reports, fee receipts — and identifies each record with some kind of reference. Usually a number. Sometimes a string. Occasionally something that looks more complex but isn't.
When an application exposes that reference directly in a URL or API call and does not verify whether the person making the request is authorised to access that specific record, it has an IDOR vulnerability.
The simplest possible example:
https://example.com/profile?id=1042
If changing 1042 to 1043 returns someone else's profile — and the server does nothing to stop it — that is IDOR.
It sounds almost too simple to be real. It is real, and it is everywhere.
Why It Persists
IDOR is not a technical failure in the way a buffer overflow is a technical failure. It is an authorisation failure — the application built the feature, made it work, and forgot to ask the most important question at each step: is this person allowed to see this?
Several factors make it particularly common in India's web ecosystem:
Speed of development over security review. Most educational, government, and SME web platforms in India are built under significant time and budget pressure. Security review — if it happens at all — is a checklist of SQL injection and XSS tests. Nobody manually checks whether every endpoint enforces ownership.
Shared SaaS platforms with poor tenant isolation. A single vendor builds a platform and licenses it to dozens of schools, hospitals, or municipal bodies. If the tenant isolation logic is wrong at one endpoint, it is wrong across every client simultaneously. One flaw, platform-wide exposure.
Confidence in automated scanning. Many organisations believe that running a commercial scanner or enabling a WAF means they are "covered." Automated scanners detect known vulnerability signatures. IDOR has no signature — it requires understanding what data a particular user should be allowed to access, which no scanner can know without business context.
Sequential integer IDs. Databases assign auto-incrementing integer primary keys by default. Developers expose these IDs directly in URLs because it is the path of least resistance. A UUID (3f7a9c21-4b8e-41d2-9f03-7c6e8a2b1d54) is not guessable. 1043 is.
What Responsible Disclosure Looks Like
When a researcher finds an IDOR vulnerability — or any security vulnerability — in a system they do not own, they have a choice about what to do with that information.
The responsible path is well-established, though not always well-followed:
1. Confirm the vulnerability minimally. You need enough evidence to document the finding clearly. You do not need to enumerate every record in the database. If changing one ID to an adjacent ID returns another person's data, that is confirmation. Stop there.
2. Document what you found, not what you could do. A vulnerability report should describe the issue, demonstrate it exists, and explain the impact. It should not include a script that dumps the entire database or proof that you accessed a thousand records. The goal is to inform the vendor, not to maximise harm.
3. Report to the vendor before going public. Contact the organisation through whatever channel is available — security email, contact form, support ticket. Include the technical details, the reproduction steps, and the impact assessment. Give them a reasonable window to respond — typically 30 to 90 days, depending on severity.
4. Report to the relevant authority simultaneously. In India, CERT-In (incident@cert-in.org.in) is the national agency for cybersecurity incident reporting. Filing here creates a timestamped record of your disclosure and provides an institutional channel for follow-up if the vendor is unresponsive.
5. Publish after the window, regardless of fix status. If the vendor has not responded or not fixed the issue within the agreed window, responsible disclosure permits — and in the public interest, encourages — publication. The community's ability to understand and avoid vulnerable platforms depends on this information being available.
The CBSE Pattern
In 2024 and 2025, multiple Indian security researchers documented critical vulnerabilities in the CBSE Online Service Module (OSM) portal — a platform used by millions of students and schools. The findings included client-side OTP validation (the server sent the OTP to the browser, where it could be read from the network tab), missing authentication on internal routes, and hardcoded credentials in JavaScript bundles.
Researchers reported these findings. CERT-In was notified. Some findings were documented publicly.
The response from CBSE and the Ministry of Education was, largely, silence followed by denial.
This pattern — serious vulnerabilities found, responsibly reported, officially dismissed — is not unique to CBSE. It reflects a structural problem in how Indian institutions treat security research. Researchers are rarely rewarded, sometimes threatened, and almost never formally acknowledged. The culture of bug bounties and responsible disclosure that is now standard in the private technology sector has not meaningfully reached India's educational and government web infrastructure.
This is a public interest failure. Eighteen lakh students' data does not become less sensitive because the organisation that holds it finds the disclosure inconvenient.
What Good Looks Like
For contrast: when a vulnerability is reported to an organisation that takes security seriously, the process looks like this.
Within 24 hours: acknowledgement of the report. Within 72 hours: assignment to a technical team and initial assessment. Within two weeks: status update to the researcher. Within 30–60 days: remediation of critical findings and verification with the researcher. After remediation: public acknowledgement of the researcher's contribution.
This is not an unrealistic standard. It is what major technology companies do as a matter of routine. It is what Indian institutions should aspire to as they digitalise at scale.
A Note on Tooling and Method
A common misconception is that finding security vulnerabilities requires sophisticated tools, deep technical expertise, or access to proprietary software.
The vulnerabilities described in my own research — documented separately on this site — were found using:
- A standard web browser with DevTools open
- The Network tab (to inspect HTTP requests and responses)
- The Console tab (to run two lines of JavaScript)
curl(a command-line tool installed on every Mac and Linux system by default)
No exploit frameworks. No automated scanners. No special access. Just attention, patience, and a willingness to ask: what happens if I change this number?
The sophistication required to find IDOR is not technical. It is conceptual. You need to understand that web applications are supposed to check whether you are authorised to access each resource you request — and notice when they don't.
On Being a Researcher Without a Title
I am not a certified penetration tester. I do not have a CISSP or an OSCP. I am a student with a laptop, a Raspberry Pi running Kali Linux, and a habit of reading carefully.
I have found ten confirmed vulnerabilities in a live production platform, filed responsible disclosure reports with the vendor and CERT-In, and held a meeting with the vendor's operations management to walk through the findings.
I mention this not to claim more credit than is due, but because I think it matters for other students and hobbyists who believe that security research is gated behind certifications and professional titles.
It is not. It is gated behind curiosity, patience, and the discipline to document what you find and report it properly.
The tools are free. The knowledge is available. The vulnerabilities are real and they are waiting to be found — not to be exploited, but to be fixed.
Hemant Kumar is a student security researcher and alumnus of St. Karen's High School, Patna. Contact: contactme@hemantkumarmp.in