IDOR: What It Is and Which Controls Catch It
Robin Joseph
Senior Security Consultant
Last reviewed: September 2026.
This is the vulnerability that shows up when authentication works perfectly and authorization doesn't, and it's one of the most common findings in real audits.
Insecure Direct Object Reference (IDOR) is what happens when an application correctly confirms who you are, but forgets to check whether you're actually allowed to see the specific thing you're asking for.
What Is IDOR?
Picture a URL like /invoices/1042. You're logged in, authentication passed. But if the application never checks whether invoice 1042 actually belongs to you before returning it, changing the number to 1043 shows you someone else's invoice. No exploit, no injection, just incrementing a number in the address bar.
IDOR is deceptively simple to find and painfully common, because it's easy to build authentication correctly and quietly skip the authorization check on every single endpoint that returns user-specific data.
Which Controls This Maps To
| Framework | Control | What it requires |
|---|---|---|
| ISO 27001:2022 | A.5.15 (Access control) | Access to information restricted according to a defined policy, enforced consistently, not just at login |
| ISO 27001:2022 | A.8.3 (Information access restriction) | Application-level enforcement that users can only reach the specific data they're authorized to see |
| SOC 2 | CC6.1 (Logical access controls) | Logical access to data restricted to authorized users, IDOR is a direct violation of this criterion in practice |
What Auditors Actually Check
IDOR is one of the most commonly cited findings in penetration test reports specifically because it's straightforward to test, incrementing or guessing IDs across every endpoint that returns user-specific data. Auditors expect to see evidence that authorization checks (not just authentication) are enforced on every request, and that this is tested regularly, not assumed to be correct because it was correct once.
How to Prevent It
- Check authorization on every request that returns or modifies user-specific data, never rely on the ID being "hard to guess" as a security measure.
- Use indirect references (a session-scoped mapping instead of raw database IDs) where practical, as a defense-in-depth layer.
- Include IDOR testing explicitly in your regular penetration testing scope, it's cheap to test and commonly missed in code review.
Frequently Asked Questions
IDOR is a specific, very common pattern of access control failure, it's what happens when authentication works but per-object authorization checks are missing. It's called out separately because it's so frequent and so easy to test for.
Because it's easy to correctly build login/authentication once and then forget to add an authorization check on every single endpoint that follows, especially as an application grows and new endpoints get added over time.
CC6.1 (logical access controls) most directly, IDOR is functionally a failure to restrict data access to authorized users, which is exactly what that criterion is designed to prevent.
Want to know where a gap like this would actually show up in your ISO 27001 or SOC 2 audit? Book a demo and we'll walk through it.