July 20, 2026

Hunting an Unauthenticated IDOR in a Registration API

Introduction

By Adham Mohamed

2 min read

While assessing the registration workflow of a web application during a bug bounty engagement, I came across an interesting API request that caught my attention. Registration endpoints are often overlooked because they are assumed to contain only temporary data, but they can sometimes expose sensitive information if proper access controls are missing.

In this write-up, I'll explain how I identified an Unauthenticated Insecure Direct Object Reference (IDOR) that allowed anyone on the Internet to retrieve registration information without logging in.

> Disclaimer: Sensitive information has been redacted, and all identifying details have been removed.

Target Recon

I started by walking through the user registration process while intercepting requests with Burp Suite.

During the registration flow, one request immediately stood out:

GET /api/SignUp/FindRegisterInfo?IncidentId=<incident_id>

The endpoint was hosted on a dedicated account API:

[https://account-api.example.com](https://account-api.example.com)

The name of the endpoint suggested that it retrieved information related to a registration incident.

At this stage, I had two questions:

Does this endpoint require authentication? Does it validate ownership of the supplied IncidentId?

Initial Testing

The application returned registration details when the request was sent with a valid IncidentId.

The next logical step was to determine whether authentication was actually required.

I removed every cookie and authentication header from the request and sent it again.

Surprisingly, the response was exactly the same.

The endpoint continued to return the registration information even though no authenticated session existed.

This indicated that the endpoint was publicly accessible.

Verifying the Finding

To ensure the behavior wasn't tied to my session, I performed several additional tests.

First, I repeated the request from a different IP address.

The endpoint continued to return the same data.

Next, I modified the IncidentId to another valid identifier.

Again, the API returned registration information belonging to a different registration record.

At this point, it became clear that the endpoint relied entirely on the user-controlled IncidentId without enforcing authentication or authorization.

Proof of Concept

Request

GET /api/SignUp/FindRegisterInfo?IncidentId=<valid_incident_id> HTTP/2
Host: account-api.example.com

Response (Redacted)

{
 "email": "[victim@example.com](mailto:victim@example.com)",
 "nickname": "victim",
 "incidentId": "…",
 …
}

The same response was returned after:

Removing all cookies. Removing authorization headers. Sending the request from another IP address.

Root Cause

The endpoint trusted a client-supplied identifier (IncidentId) and returned the associated registration information without verifying whether the requester was authorized to access it.

In other words:

No authentication check. No ownership validation. Direct object access based solely on a user-controlled identifier.

This is a classic example of an Unauthenticated IDOR.

Security Impact

An attacker possessing a valid IncidentId could retrieve registration information without logging in.

The exposed information included:

Email addresses User nicknames Internal registration identifiers

Such exposure may enable:

User enumeration Privacy violations Targeted phishing campaigns Correlation of internal registration records

Because the endpoint was publicly accessible, the attack surface extended beyond authenticated users.

Severity Discussion

Although the vulnerability allowed unauthorized access to sensitive registration data, the program ultimately classified it as Low Severity.

The reason was that the IncidentId consisted of a 24-character hexadecimal identifier, providing a sufficiently large search space to make brute-force enumeration impractical.

This highlights an important lesson in bug bounty hunting:

A vulnerability's severity depends not only on what is exposed, but also on how realistically it can be exploited.

Even though random guessing was infeasible, the authorization flaw still existed. If an attacker were to obtain a valid IncidentId through logs, browser history, referrer leakage, screenshots, or another vulnerability, they could immediately retrieve another user's registration information.

Remediation

The issue can be addressed by implementing proper object-level authorization:

Require authentication before accessing the endpoint. Verify that the authenticated user owns the requested registration record. Avoid exposing sensitive registration information unnecessarily. Continue using high-entropy identifiers, but never rely on identifier randomness as the primary security control. Add monitoring and rate limiting to detect abnormal access patterns.

Lessons Learned

This finding reinforces an important principle in web security:

Random identifiers improve security, but they do not replace authorization.

High-entropy object identifiers reduce the likelihood of successful guessing, yet every request must still be protected by proper authentication and authorization checks. Security should never depend solely on the secrecy or randomness of an identifier.

References

OWASP API Security Top 10 — Broken Object Level Authorization (BOLA) OWASP Insecure Direct Object Reference (IDOR) CWE-639: Authorization Bypass Through User-Controlled Key