How I Found an Unauthenticated IDOR in a Government College Website — A Responsible Disclosure…

Introduction

Broken access control issues are among the most impactful web vulnerabilities because they can expose data that was never intended to be public. One common form of this problem is Insecure Direct Object Reference (IDOR), where an application uses a user supplied identifier to fetch a record but fails to verify whether the requester is allowed to access it.

In this write-up, I'll walk through a real-world responsible disclosure case study involving a government college website where changing a numeric record identifier exposed records that should not have been openly accessible. I'll keep the explanation beginner-friendly and focus on the methodology, impact assessment, and reporting process, rather than exploit details.

Note: To protect affected users and the organization, I'm intentionally omitting the domain name, exact endpoint, record identifiers, and any sensitive data.

What is an IDOR?

An IDOR (Insecure Direct Object Reference) happens when an application directly references internal objects — such as user profiles, documents, invoices, or records — using identifiers like:

• id=101
• user_id=55

If the server trusts that identifier without checking authorization, an attacker may be able to replace it with another value and access a different record.

Simple example

Imagine a site uses this URL to display a document:

/page.php?id=100

If changing the id to 101 loads another person's record without authentication or authorization checks, that is a classic IDOR / broken access control issue.

How I Reproduced It

1. Opened the page that used a numeric id parameter, for example: https://example.com/page.php?id=100
2. Changed the value of the id parameter to another number, such as: https://example.com/page.php?id=101
3. Reloaded the page and observed that the application returned a different record.
4. Repeated the same with a few other values and confirmed that different IDs exposed different records without requiring authentication.
5. Since some of the returned records were not meant to be publicly accessible, this confirmed an unauthenticated IDOR / broken access control issue.

The Context of the Finding

While reviewing a government college website, I noticed a page that accepted a numeric id parameter in the URL. At first glance, it looked like a standard content page. However, the behavior changed depending on the identifier value, and some records appeared to be far more sensitive than ordinary public pages.

The key observation was this:

• the endpoint was accessible without logging in
• the response changed when the numeric identifier changed
• different identifiers returned different categories of records

That pattern is often worth investigating carefully because it can indicate direct object references backed by internal data.

What Made This a Security Issue

The issue stood out because the same endpoint was not limited to harmless public content. Minimal validation indicated that the page could expose multiple classes of records depending on the identifier value.

Examples of exposed record categories included:

• institutional documents
• student-related administrative records
• a personal official document / image associated with an individual

This moved the issue from a "content discovery quirk" into a broken access control / unauthorized information disclosure problem.

Why that matters

If an attacker can freely change an identifier and retrieve records that should not be public, the risk includes:

• exposure of personal data
• access to internal administrative records
• large-scale record harvesting if identifiers are predictable
• privacy, compliance, and reputational impact for the organization

Vulnerability Classification

I classified the issue as:

• Broken Access Control
• Insecure Direct Object Reference (IDOR)
• Unauthorized Information Disclosure

A commonly relevant CWE for this type of issue is:

• CWE-639 — Authorization Bypass Through User-Controlled Key

This CWE is useful because it captures the exact problem: the application uses a user-controlled key (such as id=100) to retrieve an object without verifying whether the requester is allowed to access it.

Reporting the Issue

Because the affected target was a government college website and the issue involved potentially sensitive data, I prepared a private responsible disclosure report rather than a public disclosure.

Final Thoughts

What I liked about this finding is that it reinforces an important lesson in web security: not every changing ID is a vulnerability, but once that same behavior starts exposing private or internal records without proper access control, it becomes a serious problem.

It was also a good reminder that finding a bug is only one part of the process. Handling it responsibly, keeping evidence minimal, and reporting it properly are just as important as identifying the issue itself.

Thank you for reading. I hope this write-up was useful, especially for beginners trying to understand how IDOR vulnerabilities can appear in real-world applications.

See you!!!!!