How a Single UUID Change Led to an IDOR Vulnerability

During one of my recent penetration testing engagements, I discovered an IDOR vulnerability with a surprisingly simple test — replacing a single UUID in an intercepted request.

How I Found It

While testing the application as a normal user, I noticed there was an option to download a file. I intercepted the download request using Burp Suite and observed that the application used a UUID to identify the requested file.

At that point, a simple question came to mind:

What if I replace this UUID with another valid UUID? Will the application verify whether I'm authorized to access that file?

To test this, I modified the UUID in the intercepted request and forwarded it. The application returned a different file instead of rejecting the request.

This confirmed that the server was relying solely on the UUID provided by the client and was not enforcing proper authorization checks.

The next step was to understand the potential impact. As part of the authorized penetration test, I also had access to an administrator account. In the admin panel, I identified a downloadable report containing sensitive user information, such as usernames, email addresses, mobile numbers, and other account-related details.

I noted the UUID associated with that administrative report and logged back into the application as a normal user. I intercepted a legitimate file download request, replaced the original UUID with the UUID of the administrator's report, and forwarded the request.

Instead of denying access, the server responded with the administrative file, allowing a normal user to download information that should have been accessible only to administrators.

This confirmed a classic Insecure Direct Object Reference (IDOR) vulnerability caused by missing server-side authorization checks. The application authenticated the user successfully but failed to verify whether that user was authorized to access the requested resource.

Impact

• A normal user could access files intended only for administrators by modifying the file UUID.
• Sensitive information could be exposed to unauthorized users due to missing server-side authorization checks.
• Confidential business documents and user data could be downloaded without the required permissions.
• The vulnerability could lead to data breaches, loss of customer trust, and reputational damage.
• Organizations may face regulatory compliance issues and financial losses if sensitive information is exposed

How to Fix It

• Add server-side authorization checks for every file download request.
• Verify that the logged-in user is allowed to access the requested file before returning it.
• Do not trust the UUID sent by the client as proof of access.
• Implement proper Role-Based Access Control (RBAC) so normal users cannot access admin-only files.
• Map each file to its owner, role, or permission level in the backend.
• Return 403 Forbidden if the user does not have permission to access the file.
• Log unauthorized access attempts for monitoring and incident detection.

Where else I've seen this exact pattern

Honestly? Constantly. I've hit the same style of bug in TryHackMe and Hackthebox rooms — a ticket ID here, a profile parameter there, swap it and you're looking at someone else's stuff. Labs or real client work, doesn't matter — the underlying mistake is identical: the app trusts the ID instead of checking the person holding it.