Quick answer: IDOR (Insecure Direct Object Reference) is when a user can access another person's data simply by changing an identifier in the address bar or request. For example, if your invoice is at siteproject.com/invoice/1043 and typing 1044 opens another customer's invoice, there is an IDOR. It falls under the broader class of Broken Access Control, which is number one on the OWASP Top 10 2021. The root cause is always the same: the server does not check, on every request, whether the requester has the right to that resource. The fix is to enforce authorization always on the server side and scoped to the resource owner, never on the client.

Access control flaws are among the technically simplest but highest impact vulnerabilities. Finding a SQL injection takes skill; finding an IDOR is often just incrementing a number. Yet, perhaps for that very reason, they are very common. This article explains the types of IDOR and Broken Access Control, how they are found and how to defend properly.

Types of Broken Access Control

Access control must answer two questions: "Who is this?" (authentication) and "Can this person do this?" (authorization). Broken Access Control is answering the second one wrong.

  • Horizontal privilege escalation (IDOR). Accessing another same level user's data. Seeing someone else's invoice instead of your own.
  • Vertical privilege escalation. A normal user reaching admin functions, for example entering an admin panel just by guessing the address.
  • Missing function level control. Actions hidden in the interface but not protected on the server. Assuming safety because a button is not visible.
  • Trusting the client. Hiding authorization only in the UI and not checking it on the server.

How IDOR is found

The logic is simple: look at how the app references objects and change that reference.

Reference type Example Risk
Sequential id /order/1043 High, easy to guess
Username /profile/john Medium, enumerable
Unpredictable id (UUID) /file/9f2c... Low but not enough alone
File path /download?file=report.pdf Open to path traversal

The critical misconception: using an unpredictable id (UUID) hides but does not fix IDOR. If the id leaks (in a log, a share link, a redirect) and the server still does no ownership check, the flaw remains. UUID is an obstacle, not a security control.

Why it is so common

  • Automated scanners struggle. IDOR needs business context. A scanner cannot know that 1043 and 1044 belong to different users. So automated vulnerability scanning misses most IDOR; human eyes are needed.
  • Developers assume "who would access it." They think one who does not know the link cannot access it. But links are shared, leaked and guessed.
  • Scattered authorization in microservices. Each service assumes another does the check, and none does.

Proper defense

1. Server side authorization on every request

The golden rule: on every resource request, the server must ask "can this session access this resource." The query must be scoped by the session user's id. So instead of "fetch invoice 1044," write "fetch this user's invoice 1044"; if the record belongs to someone else, it never returns.

2. Centralized authorization

If checks are written separately at every endpoint, one gets forgotten. A central layer or policy engine decides in one place. The identity and access management (IAM) approach is the foundation.

3. Default deny

Access must be denied unless explicitly allowed. When a new endpoint is added, the default must be safe.

4. Indirect references

Using session specific indirect references instead of the direct database id adds a layer. But it does not replace server side ownership checks; use it alongside.

Real impact

IDOR and Broken Access Control are among the most frequent causes of data breaches. Incrementing a user id can expose thousands of customers' data. This can become an incident requiring a personal data breach notification. So access control is one of the top priority checks in web application penetration testing.

Frequently asked questions

Are IDOR and Broken Access Control the same? IDOR is a subtype of Broken Access Control. Broken Access Control is the broader umbrella; IDOR is its best known example.

Does using UUID end IDOR? No. UUID makes guessing harder but does not replace ownership checks. If the id leaks, the flaw remains. The server must authorize on every request.

Can an automated scanner find IDOR? Usually not, because business context is needed. Manual testing and comparing with two accounts is the most effective method.

Is removing the button from the UI enough? No. Hiding in the UI is not security. The server must check the authorization of anyone requesting the function.

Sources

To detect IDOR and access control flaws in your application with two account comparison tests and a working proof, contact DSET. From our Ankara Hacettepe Teknokent laboratory we provide penetration testing and secure code review.