Home / Knowledge hub / IDOR
Knowledge hub
IDOR
Changing an id in a request and getting back someone else's record.
What it means
IDOR stands for insecure direct object reference. The application reads an identifier from the request, fetches the record and returns it, without checking that the record belongs to whoever asked. Change the number, read somebody else's data.
The identifier does not have to sit in the address bar. It can live in a form field, a JSON body, a header or a cookie. The flaw is not that the id is visible. The flaw is treating the id as proof of permission.
Why it matters
No tools and no skill are required. A curious customer finds one by accident. The same trick then works on every row in the table, so one flaw exposes your customer base rather than one account.
Automated tools struggle here. From outside, a successful response to a valid request looks exactly like software working properly. A tool has to know who owns what before it can call anything wrong, which is why these findings keep arriving through bug bounty reports instead.
How it shows up
Typical shapes: /invoices/1042 becomes /invoices/1041; a download link carrying a document id; an API call with customer_id in the body; a reset flow that accepts any account's id.
Swapping numeric ids for random ones raises the effort and nothing more. OWASP says directly that you should not rely on identifier complexity as protection. Ids leak through emails, exports, logs and support tickets anyway. The real test holds two accounts and sends each one's requests with the other's identifiers, keeping the request and response that proved it.
Questions people ask
IDOR, answered
Are UUIDs enough to stop IDOR?
No. An unguessable id makes guessing harder, and guessing is not the only way an attacker gets one. Ids turn up in shared links, screenshots, exports, referrer headers and other API responses.
Keep the random ids as a second layer if you like them. The fix is the ownership check on the server.
Is IDOR the same as broken access control?
IDOR is one kind of broken access control, not a separate family. Broken access control covers everything from a missing admin check to a page that trusts a hidden form field.
IDOR names the specific case where a user-supplied identifier reaches the database without an ownership check behind it.
Is it still IDOR if the id is unpredictable?
Yes, and it is still a valid finding. If handing your application another person's identifier returns their record, the authorisation check is missing regardless of how hard that identifier was to obtain.
Bug bounty programmes accept these reports for the same reason. Obscurity is not an access control.
Why do scanners miss IDOR?
Because the response looks correct. A scanner sends a valid request, receives a 200 with a record in it, and has no way to know that the record belongs to someone else.
Detecting it requires accounts in different roles and a comparison between what each one received, which is a very different job from pattern matching on responses.
How do I test for it myself?
Create two real accounts with different data. Use the first, capture a request that names a record, then send the same request with the second account's session.
If data comes back, you have one. Check the write operations too, since a delete or an update that accepts another user's id is worse than a read.
Related
Terms that sit next to this one
BOLA
An API returns a record just because you asked for it by number.
Broken access control
An application failing to enforce its own rules about who may do what.
Horizontal privilege escalation
Reaching another user's data at your own level, not a higher one.
Authorization
Deciding what a proven user is then allowed to do.
Access control
The rules deciding which person can see or do which thing in your app.
Try changing the id yourself
We hold accounts in every role, replay each one's requests using the others' identifiers, and report exactly what came back. That is one pilot, 30 days, one application, $199.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.