IDOR (Insecure Direct Object Reference)
Imagine you're logged into an application and see:
example.com/orders/45821
You change:
45821 → 45822
And suddenly, you can see someone else's order.
No password was stolen.
No MFA was bypassed.
No malware was installed.
The application simply failed to check whether you were authorized to access that resource.
This type of vulnerability is known as IDOR — Insecure Direct Object Reference, and it is commonly associated with Broken Access Control.
What Is IDOR?
IDOR occurs when an application uses a user-controlled identifier to access a resource but fails to properly verify whether the user is authorized to access that resource.
That resource could be:
User profile
Invoice
Order
Bank statement
Customer record
Private document
Support ticket
API resource
For example:
GET /api/orders/45821
The application should verify that the currently logged-in user actually owns or has permission to access Order 45821.
If the application simply retrieves the order because the ID exists, it may be vulnerable.
Knowing an object's ID does not mean you should be allowed to access it.
How Does IDOR Happen?
A vulnerable application may follow this process:
User Request → Object ID → Database → Response
The application receives an ID and retrieves the corresponding object.
The problem occurs when the application doesn't perform an authorization check before returning the information.
A secure application should follow:
User Request → Authenticate User → Identify Resource → Check Authorization → Allow or Deny
Authentication answers:
"Who are you?"
Authorization answers:
"Are you allowed to access this resource?"
IDOR usually occurs when authentication exists but authorization is missing or incorrectly implemented.
Realistic Example – E-Commerce Application
Imagine an e-commerce application where customers can view their orders.
A customer logs in and sees:
example.com/orders/45821
Order 45821 belongs to that customer.
During an authorized security assessment, a penetration tester notices that the order ID is included in the URL.
The tester changes it to:
example.com/orders/45822
If the application returns another customer's order, the application has an access-control vulnerability.
The attacker didn't need the other customer's password.
They simply requested an object they weren't authorized to access.
Lesson: An identifier is not an authorization mechanism.
IDOR in APIs
IDOR is especially important in modern APIs.
For example:
GET /api/v1/accounts/1001/transactions
A mobile application may use the account ID to retrieve transaction information.
If the backend only checks whether the user is logged in but doesn't verify whether that user owns Account 1001, another user could potentially access information belonging to someone else.
This is why API authorization testing is critical.
An API endpoint requiring authentication is not automatically secure.
The application must also determine whether the authenticated user has permission to access the requested object.
IDOR Isn't Always a Number
The name IDOR can make it sound like the vulnerability only happens when someone changes a number.
That's not true.
Object references can include:
Numeric IDs
UUIDs
Usernames
Email addresses
Invoice numbers
File names
Account IDs
Document IDs
For example:
/api/document/abc123
Changing abc123 to another valid document identifier could potentially expose another user's document if authorization isn't properly enforced.
Even unpredictable identifiers such as UUIDs are not a replacement for authorization.
What Can Attackers Access?
The impact depends on what the application exposes.
A successful IDOR vulnerability could potentially allow unauthorized access to:
Personal information
Customer records
Invoices
Financial information
Private documents
Support tickets
Order history
Healthcare information
Internal business records
And IDOR isn't limited to reading data.
In some cases, attackers may be able to modify or delete resources.
For example:
GET /api/profile/1002
might expose another user's profile.
But a vulnerable:
PUT /api/profile/1002
could potentially allow an attacker to modify it.
A vulnerable:
DELETE /api/orders/1002
could potentially allow unauthorized deletion.
IDOR vs Authentication Bypass
These vulnerabilities are often confused.
Authentication Bypass
The attacker gains access without properly authenticating.
IDOR
The attacker may be properly authenticated but accesses an object they aren't authorized to access.
For example:
Authentication:
"I'm a legitimate user, and I successfully logged in."
Authorization:
"I'm allowed to access Account 1001, but I'm not allowed to access Account 1002."
If the application fails to enforce the second rule, IDOR can occur.
How to Prevent IDOR
1. Enforce Authorization on the Server
Every request for a protected object should be checked against the user's permissions.
Never rely on the frontend to hide resources.
The server must enforce authorization.
2. Don't Trust Object IDs
Never assume that because a user knows an object ID, they are allowed to access it.
The application should verify ownership or permission.
3. Implement Object-Level Authorization
For every sensitive API request, check:
Who is making the request?
What resource are they requesting?
Does this user have permission to access that resource?
4. Apply Least Privilege
Users should only have access to the resources required for their role.
A customer should access their own orders.
A support employee may access assigned customer records.
An administrator may have broader access.
5. Don't Rely on UUIDs Alone
UUIDs can make identifiers harder to guess, but they do not solve the underlying authorization problem.
Even if an attacker obtains a valid UUID, the server must still verify authorization.
6. Test Read and Write Operations
Security testing shouldn't only check GET requests.
Authorization should be tested across:
GET → POST → PUT → PATCH → DELETE
A user might be prevented from viewing another user's information but still be able to modify or delete it.
How VAPT Teams Test for IDOR
During an authorized penetration test, testers can use two controlled test accounts.
The basic process is:
Create User A and User B.
Log in as User A.
Identify requests containing object identifiers.
Identify resources belonging to User B.
Attempt to access User B's test resource while authenticated as User A.
Compare the server response.
Test authorized read, update, and delete operations where applicable.
Document the evidence and business impact.
Recommend remediation.
Retest after the fix.
The expected behavior is:
User A → Resource A → Allowed
User A → Resource B → Denied
The goal is to validate the vulnerability without accessing unrelated real users' information.
What Can SOC Teams Monitor?
IDOR is primarily an application-security and access-control issue, but SOC teams can still help detect suspicious behavior.
Useful signals include:
A user accessing many sequential object IDs
Repeated 403 or authorization failures
One account requesting resources belonging to multiple users
Unusual API enumeration
Access to large numbers of unrelated records
Sudden spikes in API requests
Unusual access patterns from normally inactive accounts
For example:
User A → 1001 → 1002 → 1003 → 1004 → 1005...
A pattern like this could indicate automated resource enumeration and should be investigated.
Why IDOR Is Dangerous
IDOR can be particularly dangerous because the attacker may not need sophisticated exploitation techniques.
The attacker may already have:
A valid account
A valid session
A normal browser
A legitimate API request
The vulnerability exists because the application incorrectly assumes:
"If you're logged in, you can access the resource you requested."
But secure applications need to ask another question:
"Are you authorized to access this specific resource?"
Final Thoughts
IDOR demonstrates an important lesson in application security:
Knowing the address of a resource doesn't mean you should be allowed to access it.
Changing one number shouldn't expose another customer's invoice.
Changing one ID shouldn't reveal another user's profile.
Changing one API parameter shouldn't provide access to another company's data.
The solution isn't simply hiding identifiers.
The real defense is strong, server-side authorization for every protected resource.
Remember: Authentication tells you who the user is. Authorization determines what the user is allowed to do.
Comments 0
Email-verified comments are reviewed before they are published.