IDOR: Insecure Direct Object References Explained

An IDOR, or insecure direct object reference, is a flaw where an application trusts an identifier sent by the user and returns or changes the matching record without checking ownership. If /invoices/10482 shows your invoice and /invoices/10483 shows a stranger’s, the application has an IDOR. It is one of the most common serious findings in web and API testing, because the code works perfectly for honest users.

What is an IDOR vulnerability?

It is a missing authorisation check on a single object. The user has logged in, so authentication worked; what failed is the question “may this user see this record?”. OWASP files IDOR under Broken Access Control, the first category in the OWASP Top 10, and it maps to CWE-639.

The object can be anything the application looks up by reference: a database row, a file, an order, a message thread, a user profile or a whole customer tenant. The reference can sit in the URL path, a query string, a form field, a JSON body, a cookie or a header.

What does an IDOR attack look like in practice?

The simplest IDOR attack takes one request and one changed number. A customer signed in as account A asks the API for their own order, then sends the same request with the same session token but adds one to the order number:

The server checked that the token was valid but never checked that order 48214 belongs to account A, so anyone with an account can read every order by counting through the IDs. The same flaw turns up in many places:

Reading data is the classic case, but write and delete IDORs are often worse: they let an attacker change bank details, cancel orders or take over accounts. In APIs the same flaw is called broken object level authorisation (BOLA), the first entry in the OWASP API Security Top 10 (2023). A close relative, broken function level authorisation, lets an ordinary user call an admin action directly.

Why do scanners miss IDOR?

Because the vulnerable response looks normal. A scanner sees a request for invoice 10483 return a 200 status and a well-formed page; it has no way of knowing the invoice belongs to someone else. Finding IDOR needs business context: who owns which object and who should see what.

Random identifiers do not close the gap either. UUIDs are harder to guess, but they leak through shared links, logs and other API responses, and the missing check is still missing.

How do you prevent IDOR?

Check authorisation on the server, for every object, on every request. In practice:

1. Scope queries to the user. Look records up through the current user or tenant (“this user’s orders where ID is x”) rather than fetching by ID alone.
2. Centralise the rule. Put object-level checks in shared middleware or a policy layer, deny by default, so a new endpoint cannot forget them.
3. Take identity from the session. Never trust a user, account or tenant ID sent by the client when the server already knows who is logged in.
4. Treat unpredictable IDs as defence in depth only, as the OWASP IDOR prevention cheat sheet advises.
5. Write negative tests. Automated tests that log in as user A and request user B’s objects catch regressions before release.
6. Alert on enumeration, such as one session requesting hundreds of sequential IDs.

For card payment environments, PCI DSS v4.0.1 Requirement 6.2.4 requires software engineering techniques that prevent or mitigate common attacks on bespoke and custom software, including attacks on access control mechanisms, so object-level checks are part of meeting it. A secure source code review is an efficient way to confirm every data access path applies the check.

How do penetration testers check for IDOR?

A tester maps every place the application accepts an identifier, then replays each request with a second account’s session, or with another user’s ID, and compares the responses. OWASP’s Web Security Testing Guide (test WSTG-ATHZ-04) says the best approach uses at least two users, often more, that own different objects. A thorough test covers:

• Two or more accounts per role, plus accounts in separate tenants for multi-tenant products
• Every action, not just reads: create, update, delete and export
• Identifiers in paths, bodies, headers, cookies and GraphQL queries
• IDs leaked in one response and reused in another
• Mobile and API back ends, which often lack checks the web front end appears to enforce

Give your tester accounts in each role before the test starts; without them, access control coverage is thin. This is standard in our web application penetration testing and API penetration testing, and the OWASP ASVS authorisation chapter is a useful checklist for what “fixed” should mean.

Why Sovereign Secure?

Sovereign Secure is a PCI SSC-approved QSA company and ISO 27001 certified. We test web applications, APIs, mobile apps, cloud and networks manually and review source code, so access control is tested with accounts in each of your roles rather than left to a scanner, and reports stand up as PCI DSS and ISO 27001 evidence.

To have an application or API checked for IDOR and other access control flaws, request a penetration testing quote, or browse the rest of our cyber security glossary.