Insecure Direct Object Reference, commonly shortened to IDOR, is an access-control vulnerability that allows a user to access or modify an object by changing an identifier in a request.
The object might be:
- A user account
- An invoice
- A private message
- A document
- An order
- A support ticket
- A payment method
- A medical record
- A project
- An uploaded file
An application may require the user to sign in but fail to verify whether the requested object actually belongs to that user. Changing the identifier can then expose another person’s information or allow an unauthorized action.
IDOR is not primarily a problem with predictable numbers. The underlying problem is a missing object-level authorization check. Random identifiers can reduce easy guessing, but they do not correct the missing permission check.
OWASP defines IDOR as an access-control vulnerability in which an application exposes an internal object reference and fails to verify that the requester is authorized to access the referenced object. It is classified under Broken Access Control in the OWASP Top 10. OWASP’s IDOR overview explains the weakness.
What Is a Direct Object Reference?
A direct object reference is an identifier an application uses to locate a specific resource.
Examples include:
- Database record IDs
- Usernames
- Account numbers
- File names
- Document keys
- Order numbers
- Message IDs
- Project slugs
- UUIDs
- Storage paths
- Email addresses
- Transaction references
Direct object references are not inherently unsafe. Applications need identifiers to select data.
The vulnerability occurs when the server retrieves or changes the referenced object without checking whether the current user has permission to perform that operation.
How Does an IDOR Vulnerability Work?
A typical IDOR attack follows this pattern:
- A user signs in to their own legitimate account.
- The application displays a resource belonging to that user.
- The request contains an object identifier.
- The user changes the identifier.
- The server locates a different object.
- The application fails to verify ownership or permission.
- The user receives or modifies the unauthorized object.
The application may correctly verify the user’s session while still failing to authorize the individual object.
This distinction is crucial: authentication proves that the requester is a valid user, but it does not prove that the requester may access every record in the system.
Why Is IDOR Dangerous?
IDOR can provide direct access to sensitive business data through normal application functions.
An attacker may not need malicious software, stolen administrator credentials, or a complicated technical exploit. They may simply alter a request that the application already understands.
Possible consequences include:
- Exposure of personal information
- Account takeover
- Unauthorized document access
- Medical-data disclosure
- Financial-data theft
- Reading private messages
- Changing another user’s profile
- Canceling orders or reservations
- Modifying payment details
- Deleting files
- Cross-tenant data exposure
- Administrative privilege escalation
- Large-scale data scraping
- Regulatory and privacy violations
The impact depends on the type of object and whether the vulnerable endpoint provides read, create, update, or delete access.
The Three Main Ingredients of IDOR
Most IDOR vulnerabilities involve three elements:
A User-Controlled Identifier
The request contains a value the user can change.
It may appear in:
- A URL path
- A query parameter
- A form field
- A JSON body
- A cookie
- An HTTP header
- A GraphQL variable
- A WebSocket message
- A mobile application request
A Reference to an Internal Object
The value identifies a resource inside the application.
This could be a database row, file, message, account, transaction, or other stored object.
A Missing Authorization Check
The server accepts the identifier and performs the operation without confirming that the current user is authorized for that specific object.
OWASP’s prevention guidance identifies these same elements: an attacker-controllable identifier, a referenced object, and insufficient access-control validation. OWASP’s IDOR Prevention Cheat Sheet provides defensive recommendations.
Common Types of IDOR
Read-Based IDOR
A read-based IDOR allows a user to view information they should not see.
Potential targets include:
- Account profiles
- Invoices
- Documents
- Messages
- Contact information
- Financial records
- Support tickets
- Order histories
- Private images
- Application logs
Read-only access can still cause a serious data breach.
Write-Based IDOR
A write-based IDOR allows an attacker to change another user’s object.
They may be able to:
- Edit profile information
- Change an email address
- Replace a delivery address
- Modify a document
- Update a support ticket
- Change notification settings
- Alter an order
- Rename or move a file
Write access may lead to account takeover or financial harm even when the attacker cannot read the original data.
Delete-Based IDOR
A vulnerable delete function may let one user remove another person’s resources.
Possible targets include:
- Uploaded files
- Messages
- Projects
- Orders
- API keys
- Devices
- User accounts
- Backups
Deletion endpoints require the same object-level authorization as read and update endpoints.
Horizontal IDOR
Horizontal IDOR occurs when one user accesses an object belonging to another user at the same general privilege level.
For example, one customer views another customer’s invoice.
This is the most common form of IDOR.
Vertical IDOR
Vertical IDOR occurs when an object reference gives a lower-privileged user access to an administrator’s object or a privileged function.
For example, a normal user might change the identifier associated with a role record or administrative configuration.
Vertical IDOR may lead to privilege escalation.
Cross-Tenant IDOR
A cross-tenant IDOR allows a user in one organization to access resources belonging to another organization.
This is particularly dangerous in:
- Software-as-a-Service platforms
- Business dashboards
- Cloud-management tools
- Accounting systems
- Healthcare platforms
- Collaboration applications
- Customer portals
Tenant isolation must be enforced separately from ordinary user authentication.
File-Based IDOR
A download or preview endpoint may accept a filename, storage key, or document ID without verifying ownership.
Changing the reference may expose:
- Contracts
- Identity documents
- Reports
- Medical files
- Private images
- Source archives
- Backups
- Financial exports
A random filename does not replace authorization.
API IDOR
APIs frequently expose object identifiers directly through URLs and structured requests.
A mobile or web frontend may hide the identifier from ordinary users, but the API request remains visible to anyone who controls their device.
Every API endpoint must perform object-level authorization independently.
GraphQL IDOR
A GraphQL operation may accept an ID for a user, document, project, or transaction.
The resolver might correctly retrieve the object but fail to confirm whether the current requester may access it.
GraphQL authorization must be applied at the resolver, service, or data-access layer for every protected object and field.
WebSocket IDOR
WebSocket applications use persistent connections, but each message may still request a specific object or action.
A user who is authenticated to the connection should not automatically gain access to every channel, room, conversation, or record.
Authorization should be checked when the subscription begins and when relevant access conditions change.
Mobile Application IDOR
Mobile applications often communicate directly with backend APIs.
Interface restrictions inside the mobile application do not secure those APIs. A user can inspect or reproduce requests independently.
The backend must check object ownership and permissions for every operation.
Bulk-Operation IDOR
A batch endpoint may accept a list of object identifiers.
Even if the user is authorized for some objects in the list, the server must check every object individually.
Bulk export, bulk deletion, and bulk update features can turn one missing authorization check into a large data breach.
Nested-Object IDOR
An endpoint may check access to the parent object but not the nested resource.
For example, a user may legitimately access one project but supply the identifier of a file belonging to another project.
The server must validate the full relationship among:
- User
- Tenant
- Parent resource
- Child resource
- Requested action
Second-Order IDOR
A second-order IDOR occurs when an unauthorized object reference is stored and used later.
A user might save a document ID, recipient ID, export target, or project reference. A background job later processes it without checking authorization again.
Because submission and execution are separated, the vulnerability may be difficult to identify.
What Is the Difference Between IDOR and BOLA?
Broken Object-Level Authorization, or BOLA, is a term commonly used in API security.
Both IDOR and BOLA describe an application that fails to verify whether a user may access a particular object.
The terminology differs slightly:
- IDOR emphasizes manipulation of a direct object reference.
- BOLA emphasizes the missing object-level authorization decision.
- IDOR is widely used for websites and applications.
- BOLA is especially common in discussions of API security.
OWASP’s API testing guidance defines BOLA as an API failure to enforce authorization for each requested object, allowing attackers to manipulate IDs, GUIDs, or tokens. OWASP’s BOLA testing guidance explains the issue.
What Is the Difference Between IDOR and Broken Access Control?
Broken access control is the broad category.
IDOR is one specific type involving references to objects.
Other broken access-control vulnerabilities include:
- Access to administrator functions
- Missing role checks
- Workflow bypass
- Client-side authorization
- Cross-origin authorization errors
- Exposed sensitive fields
- Unprotected API methods
Every IDOR is a broken access-control vulnerability, but not every broken access-control vulnerability is an IDOR.
What Is the Difference Between IDOR and Forced Browsing?
Forced browsing involves directly requesting an unlinked or hidden page, file, or endpoint.
IDOR involves changing an identifier to access a different internal object.
The vulnerabilities can overlap. An attacker may discover an unlinked download endpoint through forced browsing and then exploit IDOR by changing its document identifier.
What Is the Difference Between IDOR and Path Traversal?
IDOR manipulates an application-level identifier to access an unauthorized object.
Path traversal manipulates a filesystem path to escape an intended directory.
A vulnerable file-download feature may contain either or both:
- IDOR if the user can access another person’s legitimate document
- Path traversal if the user can access files outside the document directory
The server must enforce both object authorization and safe path handling.
What Is the Difference Between IDOR and SQL Injection?
SQL injection changes the structure of a database query.
IDOR uses a valid identifier in a legitimate query but exploits missing authorization.
Parameterized queries prevent SQL injection, but they do not prevent IDOR. A database query can be perfectly safe from injection while still returning another user’s record.
What Is the Difference Between IDOR and Authentication Bypass?
An authentication bypass allows someone to access the application without proving their identity.
IDOR often involves an authenticated user who accesses an object beyond their permission.
Strong authentication does not prevent IDOR because the authorization failure occurs after the user’s identity has been established.
Where Do IDOR Vulnerabilities Appear?
IDOR can exist anywhere an application accepts an object identifier.
Common locations include:
- Profile pages
- Account settings
- File downloads
- Order systems
- Invoices
- Private messages
- Support tickets
- Project-management tools
- Healthcare records
- Student portals
- Payment applications
- Reservations
- Cloud dashboards
- Administrative panels
- API endpoints
- Mobile backends
- GraphQL resolvers
- WebSocket messages
- Export functions
- Background jobs
Developers should examine both visible identifiers and those hidden inside request bodies or client-side code.
What Causes IDOR?
The root cause is a missing or incorrect object-level authorization check.
Common development mistakes include:
- Retrieving an object by ID alone
- Checking authentication but not ownership
- Trusting the frontend
- Hiding object identifiers
- Assuming UUIDs cannot be discovered
- Using client-supplied user IDs
- Applying tenant filters inconsistently
- Checking authorization only on read requests
- Forgetting update or delete operations
- Reusing privileged service functions
- Checking the parent but not the child object
- Failing to authorize bulk operations
- Trusting internal APIs
- Caching authorization incorrectly
- Using default-allow rules
- Confusing database access with user authorization
MITRE commonly maps this weakness to CWE-639: Authorization Bypass Through User-Controlled Key. The weakness occurs when a user-controlled key selects a record without sufficient permission validation. MITRE’s CWE-639 entry provides the formal description.
Warning Signs of an IDOR Attack
Security teams may observe:
- One account requesting many sequential IDs
- Requests for records belonging to unrelated users
- Cross-tenant object access
- Repeated successful and unsuccessful identifier changes
- Large numbers of document downloads
- One user accessing many accounts in a short time
- Unusual API enumeration
- Updates to objects without normal interface activity
- Deleted resources across multiple users
- Object IDs that do not match the authenticated account
- Bulk requests containing mixed ownership
- Access to old or archived objects
- Requests using leaked or expired object links
- Mobile clients requesting unrelated records
- Regular accounts accessing administrator-owned objects
Attackers may move slowly or use random-looking identifiers, so detection should focus on ownership and relationship patterns rather than sequential numbers alone.
How Can Developers Prevent IDOR?
Enforce Object-Level Authorization
Every operation involving an object must verify that the current user may perform the requested action.
This includes:
- Reading
- Creating
- Updating
- Deleting
- Downloading
- Sharing
- Exporting
- Approving
- Moving
- Archiving
Authorization should consider the user, object, tenant, relationship, requested action, and current state.
Scope Database Queries to the Current User
Instead of retrieving an object globally and checking ownership later, query through the user’s authorized collection where practical.
The application should ask for the requested object only within the records available to the current user or tenant.
This reduces the chance that an unauthorized object is returned accidentally.
Deny Access by Default
If no authorization rule explicitly permits access, deny the request.
New endpoints and object types should not become available simply because a developer forgot to configure a permission.
Enforce Authorization on the Server
Do not rely on:
- Hidden interface elements
- Disabled buttons
- Client-side route guards
- Mobile application logic
- Read-only form fields
- Obscure object IDs
- JavaScript checks
The user controls the client. The server is the security boundary.
Derive User and Tenant Identity From Trusted Context
Do not trust a user ID, account ID, or tenant ID merely because it appears in the request.
Derive identity and membership from:
- The authenticated session
- A validated access token
- Trusted server-side records
- An authorization service
If the request includes a tenant identifier, verify it against the authenticated user’s permitted tenants.
Use Centralized Authorization Policies
Authorization logic should be consistent across:
- Web pages
- APIs
- Mobile endpoints
- Background jobs
- GraphQL
- WebSockets
- Administrative tools
A centralized policy or service reduces duplicated and conflicting permission checks.
Check Every HTTP Method
A record protected from unauthorized viewing may still be vulnerable to editing or deletion.
Test and enforce authorization for all supported methods and operations.
Check Every Object in Bulk Requests
Batch endpoints should validate permission separately for every object.
Do not assume that authorization for the first item applies to the remaining list.
The system should reject unauthorized objects or fail the complete request according to a clearly defined security policy.
Validate Parent-Child Relationships
For nested resources, confirm that:
- The child belongs to the stated parent
- The parent belongs to the correct tenant
- The user may access both
- The requested operation is permitted
Do not independently trust a parent ID and child ID supplied by the client.
Use Indirect References Where Appropriate
Applications may map a public-facing identifier to an internal database key.
This can reduce information leakage and casual enumeration. However, the mapping must still be scoped to the authorized user.
Indirect references are a defense-in-depth measure, not a substitute for authorization.
Use Random Identifiers as an Additional Layer
UUIDs and other high-entropy identifiers make large-scale guessing more difficult.
They are useful, but an attacker may obtain an identifier through:
- Shared links
- Logs
- Browser history
- Referrer data
- Emails
- Analytics
- Another compromised account
- Search results
- Screenshots
Every request still needs an authorization check.
Apply Field-Level Authorization
A user may be allowed to access an object without being entitled to every field.
Create response models that expose only the permitted information.
Avoid returning entire internal objects and hiding sensitive fields only in the frontend.
Protect Files Through Controlled Endpoints
Store private files outside public web directories.
Use a download handler that:
- Authenticates the user.
- Retrieves the file record.
- Checks ownership or permission.
- Maps the record to a server-controlled storage location.
- Serves the file with appropriate headers.
If signed download URLs are used, keep them short-lived and narrowly scoped.
Repeat Authorization for Background Jobs
When an action is processed asynchronously, verify that authorization was valid for the same user, object, and operation.
Do not assume a stored object reference is safe simply because it entered the queue through an authenticated endpoint.
Protect Administrative Overrides
Support and administrative users may legitimately access objects belonging to many users.
Their elevated access should require:
- Explicit roles
- Strong authentication
- Audit logging
- A documented purpose
- Additional approval for high-impact actions
- Limited session duration
- Reauthentication where appropriate
Avoid Leaking Object Identifiers
Do not unnecessarily expose internal object keys in:
- Logs
- Error messages
- Analytics
- Public URLs
- Client-side source
- Referrer headers
- Emails
Reducing leakage is useful, but it does not eliminate the authorization requirement.
Why UUIDs Do Not Completely Prevent IDOR
UUIDs can be difficult to guess, but IDOR is not fundamentally an identifier-prediction problem.
If a user obtains another person’s UUID and the server does not check authorization, the vulnerability still exists.
OWASP recommends using complex identifiers only as defense in depth and emphasizes that access control must be checked for every object. OWASP’s IDOR Prevention Cheat Sheet makes this distinction clear.
Can Encryption Prevent IDOR?
Not by itself.
Encrypting or encoding an object identifier may make it harder to understand, but the server still needs to authorize the resulting object.
If the application decrypts a valid identifier and returns the object without checking permission, a leaked encrypted reference can still grant unauthorized access.
Can a Web Application Firewall Prevent IDOR?
A WAF may detect rapid identifier enumeration, suspicious API patterns, or large-scale downloads.
It usually cannot determine:
- Who owns an object
- Which tenant it belongs to
- Whether the user is a project member
- Whether the requested action is allowed
- Whether a business relationship exists
IDOR must be corrected through application-level authorization.
How Should IDOR Be Tested?
Testing must be performed only with explicit authorization.
A controlled assessment should use multiple test accounts with different:
- Users
- Roles
- Tenants
- Object ownership
- Workflow states
- Permission levels
Reviewers should identify every object reference in:
- URLs
- Query parameters
- Request bodies
- Cookies
- Headers
- File paths
- GraphQL variables
- WebSocket messages
- Mobile requests
Testing should verify whether one account can read, change, delete, or act on objects belonging to another test account.
OWASP’s Web Security Testing Guide recommends mapping object references and systematically checking whether changing them bypasses authorization. OWASP’s IDOR testing guidance provides the methodology.
How Can Organizations Detect IDOR Abuse?
Useful monitoring sources include:
- Application audit logs
- API gateway records
- Database access logs
- File-download logs
- Cloud-storage activity
- Authentication events
- GraphQL operation logs
- WebSocket subscription records
- Administrative activity
High-value detections include:
- One account accessing objects owned by many users
- Repeated sequential or random identifier changes
- Cross-tenant access
- Bulk exports inconsistent with the user’s role
- Large numbers of unauthorized-object responses
- Successful access immediately after denied attempts
- Updates or deletions outside normal workflows
- Support accounts accessing unusually broad datasets
What Should an Organization Do After Detecting IDOR?
Disable or Restrict the Vulnerable Endpoint
Temporarily disable the affected function or limit it to trusted administrators.
Implement an immediate server-side ownership check while the complete authorization design is reviewed.
Preserve Evidence
Collect:
- Requests
- Authentication records
- Object-access logs
- Database activity
- File downloads
- Modified records
- Deleted resources
- API gateway events
- Tenant information
- Administrative activity
Determine the Scope
Investigators should establish:
- Which object types were exposed
- Which users and tenants were affected
- Whether information was read
- Whether records were changed or deleted
- Whether access was automated
- How long the vulnerability existed
- Whether bulk data was exported
- Whether administrative objects were reached
Revoke Unauthorized Access
Depending on the incident:
- Suspend suspicious accounts
- Revoke active sessions
- Disable compromised API tokens
- Remove unauthorized sharing links
- Reverse role or ownership changes
- Block affected object references
Restore Modified Data
Use audit history and trusted backups to restore altered or deleted records.
Verify that related resources, ownership settings, and sharing permissions were not changed.
Notify Affected Users
When personal, financial, medical, or regulated information was exposed, follow applicable notification requirements.
Provide clear information about the data involved and the actions users should take.
Fix Similar Endpoints
An IDOR vulnerability often reflects a broader development pattern.
Review:
- Other operations on the same object
- Similar controllers or API routes
- Mobile endpoints
- Bulk functions
- File access
- Background jobs
- Administrative tools
- Other tenant-aware services
Continue Monitoring
After remediation, monitor for:
- Repeated requests to the old endpoint
- Use of previously downloaded data
- Attempts against related object types
- Reused sessions or API tokens
- Cross-tenant access attempts
- Further privilege escalation
Does Multi-Factor Authentication Prevent IDOR?
No.
MFA confirms the user’s identity more strongly, but IDOR is an authorization failure.
A legitimate user who completes MFA may still access another user’s object if the server does not verify permission.
Is IDOR Only a Website Vulnerability?
No.
IDOR can affect:
- APIs
- Mobile applications
- Desktop software
- Cloud platforms
- GraphQL services
- WebSockets
- Internet of Things devices
- Internal tools
- Microservices
- File-storage systems
Any system that accepts an object reference from a less trusted party may be affected.
Can IDOR Lead to Account Takeover?
Yes.
If an IDOR vulnerability allows an attacker to modify:
- Email addresses
- Password-reset destinations
- Recovery phone numbers
- Authentication devices
- API keys
- Active sessions
- Account ownership
the attacker may gain control over another user’s account.
Account-security changes should require strong object authorization and often reauthentication.
Is IDOR Included in the OWASP Top 10?
IDOR is included within Broken Access Control, ranked number one in the OWASP Top 10:2025.
OWASP lists viewing or editing another user’s account by changing its unique identifier as a core example of broken access control. OWASP Top 10:2025 explains the broader category.
