IDOR Lab: Read Someone Else’s Document by Changing One Number

This article explains Insecure Direct Object Reference (IDOR), an access-control vulnerability where applications authenticate users but fail to verify they own the resources they request. Using a hands-on lab scenario with DocuShare, it demonstrates how an attacker can read another user's document by simply changing a number in the URL, illustrating that authentication and authorization are distinct security controls. IDOR is ranked in the OWASP Top 10 and remains one of the most frequently discovered vulnerabilities in real-world applications and bug bounty programs.

• Authentication versus authorization distinctionThe article emphasizes that DocuShare performs authentication (confirming the user is logged in via a valid session) but skips authorization (verifying the user owns the document). The server receives a document ID parameter, confirms a session exists, and returns the document without ever comparing its owner to the requesting user. This gap between confirming identity and checking permissions is the core vulnerability.
• Sequential IDs enable predictable discoveryIn the lab, Sarah's documents have IDs starting at 1010 and incrementing upward (1010, 1011, etc.). Because IDs are sequential and visible in the address bar, an attacker can simply decrement the number to find other users' documents nearby, making the vulnerable resource trivially discoverable. The lab is solved by changing the ID to 1003 to access the administrator's confidential file.
• Server-side ownership check is the fixThe article prescribes that for every request, the server must load the requested object and verify the current user owns it or has been granted explicit access. This check should be centralized in one place, such as a policy layer, to prevent new endpoints from accidentally omitting the authorization step and to ensure consistent enforcement across the application.
• Unguessable IDs provide limited protectionWhile using UUIDs instead of sequential numbers makes IDs harder to guess, the article clarifies this is a 'speed bump, not a fix' because IDs leak through shared links, logs, error messages, and other responses. Random IDs reduce discoverability but do not eliminate IDOR if the server still lacks proper ownership verification.
• Real-world impact demonstrates severityThe article cites the 2019 First American Financial breach, where approximately 885 million mortgage-related records—including bank details and Social Security numbers—were exposed through URLs with sequential document IDs and no access control. This demonstrates that IDOR is not theoretical; it has directly compromised sensitive financial and personal data at scale.
• IDOR ranks within broken access controlThe article places IDOR within the broader category of Broken Access Control, which is ranked number one in the OWASP Top 10 (2021). IDOR is noted as one of the most common findings in bug bounty programs, particularly in APIs, indicating widespread prevalence.
• Two-account testing methodologyThe article recommends testing for IDOR by creating two accounts and attempting to access account B's data while logged in as account A, checking every ID encountered in URLs, JSON bodies, headers, and file names. This practical approach allows developers and security testers to identify the vulnerability before deployment.

Bottom line: IDOR is a fundamental access-control flaw where authentication succeeds but authorization is never checked; the fix is mandatory server-side verification of ownership for every object access, not reliance on obscuring IDs. Testing for IDOR with two accounts is the most reliable discovery method, and its prevalence in bug bounties and real breaches makes it a critical security priority.