What Is an Insecure Direct Object Reference (IDOR)?

What IDOR Means

An Insecure Direct Object Reference (IDOR) is a type of broken access control vulnerability where an application exposes a reference to an internal object — a database record, a file, a user account — and fails to verify that the user making the request has permission to access that specific object.

The "object reference" is typically an identifier in a URL, an API request body, or a query parameter: an order ID, a user ID, a document ID, a filename. The "insecure" part is that changing that identifier gives access to another user's data with no authorisation check.

IDOR is listed under Broken Access Control in the OWASP Top 10, which describes broken access control as the most common web application vulnerability category.

A Simple Example

A user logs into an online shopping site and views their order:

``` GET /orders/10452 ```

The application returns their order details. The user changes the ID:

``` GET /orders/10451 ```

The application returns order 10451 — belonging to a different customer — with their name, delivery address, and items ordered. No error. No authentication check. The server returned the data because the request was authenticated (the user was logged in), but never checked whether this user was entitled to see this specific order.

More Real-World Patterns

**File download via predictable path:**

``` GET /download?file=invoice_10452.pdf ```

Changing the filename to `invoice_10451.pdf` downloads another customer's invoice.

**API endpoint with user ID in request body:**

```http POST /api/update-address {"user_id": 8841, "address": "123 New Street"} ```

An attacker changes `user_id` to 8840. If the server uses the user_id from the request body rather than the authenticated session to determine which record to update, the attacker has modified another user's address.

**Message or document retrieval:**

``` GET /messages/7712 ```

Iterating through message IDs exposes private messages between other users.

**Account settings exposed by numeric ID:**

``` GET /account/settings?id=1001 ```

Changing the id parameter exposes another account's settings, including potentially their email address, phone number, or API keys.

Why IDOR Is So Common

IDOR vulnerabilities emerge because authorisation is easy to forget. Developers implement authentication — checking that the user is logged in — but miss authorisation — checking that this specific user can access this specific resource.

The error is particularly common in:

- Rapidly built applications where features are added without a consistent authorisation framework - Legacy code where ownership checks were never added to early features - API endpoints added later that lack the access controls present in the original web interface - Administrative endpoints that were assumed to be internal but became accessible

Numeric, sequential IDs make IDOR trivial to exploit: knowing your own ID is 8841, an attacker tries 8840 and 8842. UUIDs make exploitation harder (guessing a UUID is impractical) but do not fix the underlying vulnerability — if another mechanism reveals a valid UUID, the IDOR is still exploitable.

Finding IDOR in Your Application

During a security assessment, testers look for:

1. Any identifier in a URL, parameter, or request body that references a data object 2. Whether changing that identifier returns data belonging to another user 3. Whether the response differs meaningfully between a valid ID and one the tester's account should not access

Automated scanners can find some IDOR issues, but the most impactful IDOR vulnerabilities — particularly those involving business logic or non-obvious object relationships — typically require manual testing by someone who understands your application's structure.

How to Fix IDOR

**Always enforce object-level authorisation** — Every time your application retrieves or modifies an object based on a user-supplied reference, check that the authenticated user owns or has permission to access that specific object. This check must happen on the server side.

```python # Wrong — trusts the user-supplied ID without checking ownership order = Order.get(order_id) return order

# Correct — checks that the authenticated user owns this order order = Order.get(order_id) if order.user_id != current_user.id: abort(403) return order ```

**Use indirect references where appropriate** — Instead of exposing your database primary key directly, create a mapping that is specific to the user session. The application converts the user-facing reference back to the internal one server-side, and the mapping only contains references the user is permitted to access.

**Implement a centralised authorisation layer** — Rather than adding ownership checks ad hoc to each endpoint, implement authorisation as a reusable function or middleware that is applied consistently across the application. This makes it harder to miss.

**Use non-sequential identifiers** — UUIDs reduce the practical exploitability of IDOR vulnerabilities by making object references unguessable. They do not fix the vulnerability — implement proper authorisation regardless — but they raise the bar.

**Test every object reference explicitly** — During development and testing, explicitly verify that each endpoint rejects requests for objects belonging to a different user, with a 403 or 404 response.

IDOR is closely related to other broken access control issues. [What is an open redirect vulnerability](/blog/what-is-open-redirect-vulnerability) covers another access control failure that appears in a different part of the request lifecycle. [Business logic vulnerabilities](/blog/what-is-business-logic-vulnerability) covers the category of flaws — including some IDOR variants — where the application's own rules are exploited rather than a generic web attack pattern.

Yrzo AI's automated security assessment includes checks for access control weaknesses and insecure object references across your web application. From yrzoai.dev.