Overview
Insecure Direct Object Reference (IDOR) is a vulnerability where an application provides direct access to objects based on user-supplied input. An attacker can simply change an ID in a URL (e.g.,.../invoice/123 to .../invoice/124) to access data that does not belong to them. This flaw occurs because the application checks if the user is authenticated (logged in), but fails to check if they are authorized (allowed to see that specific item).
Business Impact
IDOR is a critical, high-impact vulnerability. It can lead to a complete loss of data confidentiality, allowing attackers to access and exfiltrate all user data in the system, one record at a time. They can also modify or delete other users’ data, leading to massive integrity-loss.Reference Details
CWE ID: CWE-639 (Authorization Bypass Through User-Controlled Key)
OWASP Top 10 (2021): A01:2021 - Broken Access Control
Severity: High
Framework-Specific Analysis and Remediation
This is a logical flaw that frameworks cannot prevent automatically. The vulnerability is in the data-access logic. The fix is to always filter by the authenticated user’s ID in addition to the object’s ID. Never retrieve an object by its ID alone.- Python
- Java
- .NET(C#)
- PHP
- Node.js
- Ruby
Framework Context
A Django view that retrieves an object usingInvoice.objects.get(pk=invoice_id).Vulnerable Scenario 1: A Document Detail View
Vulnerable Scenario 2: An API Update Endpoint
A DRF view that allows updating a user profile, but only checks for authentication.Mitigation and Best Practices
Modify the query to also filter onuser=request.user. For the API, the endpoint should not take a user_id from the URL; it should always operate on request.user.Secure Code Example
Testing Strategy
Write an integration test. Create two users,user_a and user_b. Create an invoice that belongs to user_b. Log in as user_a. Attempt to GET the URL for user_b’s invoice. Assert the response is a 404 Not Found.
