What Is IDOR? Insecure Direct Object References Explained

Insecure Direct Object References — IDOR — is one of the most consistently exploited vulnerabilities on the web today. It consistently ranks under OWASP A01: Broken Access Control, the number one category in the OWASP Top 10 (2021). Despite being decades old and well understood, IDOR appears in everything from government portals to Fortune 500 applications. The reason is simple: it is easy to introduce and difficult to detect without systematic testing.

What Is IDOR?

IDOR occurs when an application exposes a direct reference to an internal object — a database row, a file, a user record — and fails to verify that the requesting user is authorised to access it. The "direct reference" is typically something visible in the URL or request body: a numeric ID, a sequential order number, a UUID, or a filename.

Consider this URL: https://app.example.com/invoices/download?id=1042

If the server returns invoice 1042 to anyone who requests it — without checking whether the logged-in user owns that invoice — this is a classic IDOR vulnerability. An attacker who has access to their own invoice at ID 1043 can trivially try 1042, 1041, 1040, and so on, downloading invoices belonging to other customers.

Why IDOR Is Dangerous

The severity of an IDOR vulnerability scales with what is behind the reference:

• PII exposure — names, addresses, dates of birth, national IDs of other users
• Financial data — account numbers, payment history, invoice details
• Medical records — patient data, prescriptions, diagnoses
• Account takeover — if the reference controls a password reset token or session identifier, an attacker can take over other accounts entirely
• Privilege escalation — modifying an object reference in a write operation can grant access to admin functionality or another user's account settings

The 2020 breach at a major parking platform exposed 21 million user records because vehicle registration lookups were protected by sequential integers in the URL. An attacker enumerated IDs in sequence and retrieved the full database. This is a textbook IDOR attack, and it is not unusual.

Types of IDOR

URL Parameter IDOR

The most visible form: the object reference appears directly in the URL. /profile?user_id=5823, /order/98712/details, /download?file=report_2024_q3.pdf. Changing the parameter retrieves a different object. If the server does not verify ownership, any object is accessible.

Body Parameter IDOR

The reference appears in a POST body or JSON payload rather than the URL. A form that submits {"account_id": 5823, "action": "update_email"} is equally vulnerable if the server does not verify that account 5823 belongs to the authenticated user.

Cookie or Header IDOR

Some applications store the user ID in a cookie or custom header and use it server-side to look up the user's data. If that value is not cryptographically bound to the session, an attacker can simply replace it with another user's ID.

Indirect IDOR via Predictable References

Sequential integers are obvious candidates for enumeration, but predictable non-integer references are equally exploitable: timestamps used as filenames, sequential order numbers with a fixed prefix, or hashed identifiers created from predictable inputs (MD5 of an email address, for example) can all be enumerated or guessed.

Why IDOR Is So Common

Developers are trained to think about authentication — verifying who you are — but authorisation — what you are allowed to do — is often treated as an afterthought. When a feature is built, the developer checks that the user is logged in and then retrieves the requested object by its ID. The check "does this user own this object?" is the step that gets skipped, especially under time pressure or in legacy codebases where access control was not part of the original design.

Frameworks and ORMs make retrieving objects by ID trivially easy. They do not automatically add ownership checks. That responsibility remains with the developer, and it is easy to miss in code review because the vulnerability is not in any single line of code — it is in the absence of a line.

How Shieldome Detects IDOR Indicators

Pure IDOR requires authenticated session context and knowledge of valid object IDs to confirm — it is inherently an application-layer vulnerability that varies by codebase. However, Shieldome surfaces several indicators that dramatically increase the likelihood of IDOR being present:

• Sequential numeric IDs in URLs: Shieldome crawls your site and flags patterns where object references in URLs are sequential integers. Sequential IDs are a prerequisite for trivial IDOR enumeration — replacing them with UUIDs or opaque tokens eliminates guessability.
• Sensitive path exposure: Shieldome checks whether administrative or user-specific endpoints respond differently to unauthenticated requests versus authenticated ones, surfacing paths that may lack proper access control gates.
• Open redirect indicators: IDOR frequently co-occurs with other access control failures. Shieldome checks for open redirect parameters that can be abused to leak references across security boundaries.
• Missing authentication on sensitive routes: Shieldome probes known sensitive route patterns for authentication enforcement, flagging any that return data without requiring a valid session.

Every IDOR-related finding in a Shieldome report is classified under OWASP A01: Broken Access Control and includes the specific URL pattern and remediation recommendation.

How to Fix IDOR

The fix for IDOR is consistently the same regardless of where it appears: always verify object ownership on the server side, never trust the client-supplied reference alone.

• Query by ownership, not just by ID: Instead of SELECT * FROM invoices WHERE id = ?, use SELECT * FROM invoices WHERE id = ? AND user_id = current_user_id. If the row is not found, return 404 — not 403, which confirms the resource exists.
• Use non-guessable references: Replace sequential integer IDs with UUIDs or HMAC-signed tokens in all user-facing references. This does not eliminate IDOR but raises the bar for enumeration significantly.
• Centralise access control logic: Implement ownership checks in a single authorisation layer — middleware, a policy class, or a repository pattern — rather than duplicating the check in every route handler. Centralised checks are harder to accidentally omit.
• Test for it explicitly: Register two accounts in your own application and attempt to access objects belonging to account A while authenticated as account B. If it works, you have IDOR. Automated scanners can identify indicators; manual testing confirms exploitability.

Frequently Asked Questions

Is IDOR the same as broken access control?

IDOR is a specific type of broken access control. Broken access control (OWASP A01) is the broader category covering any case where a user can perform actions or access data they should not be authorised for. IDOR is the specific pattern where the vulnerability is triggered by manipulating a direct reference to an object — typically an ID in a URL or request body. Other broken access control patterns include privilege escalation via role manipulation and forced browsing to restricted pages.

Does HTTPS prevent IDOR?

No. HTTPS encrypts the connection between client and server, preventing eavesdropping. It does nothing to prevent an authenticated user from manipulating request parameters to access other users' data. IDOR is an application-layer vulnerability; HTTPS is a transport-layer control. Both are necessary and independent of each other.

Can a WAF block IDOR attacks?

Generally no. Web Application Firewalls work well against injection attacks with identifiable malicious payloads. An IDOR attack looks like a normal authenticated request — the only difference is the ID value. A WAF cannot know which ID values are owned by which users. Proper server-side authorisation checks are the only reliable defence.

Are UUIDs sufficient to prevent IDOR?

UUIDs make guessing impractical but do not eliminate IDOR. If an attacker obtains a UUID they should not have — through a shared link, a log entry, or another vulnerability — and the server does not check ownership, they can still access the resource. UUIDs reduce enumeration risk; authorisation checks eliminate the underlying vulnerability.

How does Shieldome help me find IDOR before attackers do?

Shieldome automatically crawls your site, identifies URL patterns with sequential or predictable object references, and flags them as access control risk indicators in your report. It also checks whether sensitive routes return data without authentication. These findings point your development team to the routes most likely to contain IDOR vulnerabilities, so manual verification can focus where it matters most. Run a free scan today to see what Shieldome finds on your site.