Information Disclosure Through Unrestricted API Endpoints

Information Disclosure Through Unrestricted API Endpoints | by DrRobik - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original Information Disclosure Through Unrestricted API Endpoints During one of my usual bug hunting sessions, I was exploring a website that I'll call target.com to keep things anonymous. I was testing… DrRobik Follow ~2 min read · April 5, 2026 (Updated: April 5, 2026) · Free: Yes During one of my usual bug hunting sessions, I was exploring a website that I'll call target.com to keep things anonymous. I was testing with a low-privileged account, basically a viewer, and at first, everything seemed completely normal. As a viewer, I couldn't access the users panel, roles, or any sensitive project information. The UI clearly restricted everything, and I assumed the backend was enforcing the same rules. It looked like a simple, well-protected platform — nothing obvious to test. But I kept thinking: just because I can't see it in the UI doesn't mean the backend won't give it to me if I ask directly. Experimenting with Permissions To test this idea, I temporarily upgraded my account to Project Manager using an admin account. Suddenly, new options appeared: the users panel, role management, and more API activity that I could intercept in Burp Suite. While browsing, I captured a request that updates user roles: POST /api/project-management/{projectId}/people/{userId}/updateroles I didn't do anything with it yet; I just sent it to Repeater and saved it. Next, I switched back to a normal viewer by removing all elevated privileges from my test account. The UI correctly reflected the downgrade: no access to users, no roles tab, nothing hidden behind permissions. Trying Old Requests I remembered the saved request in Repeater and decided to experiment. I changed the method from POST to GET and simplified the endpoint: GET /api/project-management/ I sent it — and it returned data. At first, it was only project-level details, but it already seemed like more than a normal viewer should see. I kept exploring. Discovering the Issue Next, I tried these endpoints: GET /api/project-management/{projectId} GET /api/project-management/{projectId}/people/ The results were clear. Even as a viewer, I could access: All users in the project Their emails and internal IDs Role assignments Admin indicators None of this information should have been visible to a user with view-only permissions. What Happened The frontend correctly hides sensitive data. But the backend doesn't enforce the same restrictions. Any user who knows the endpoints can request the data directly. This isn't about modifying anything — I couldn't change any roles or user data. But the information itself is sensitive and shouldn't be exposed to viewers. Why This Matters Even read-only access can be valuable. With this data, someone could: Identify project admins Map out the team structure Collect internal IDs for future testing Understand how roles and permissions are organized So even without write access, this is a serious information disclosure that could help an attacker plan further attacks. #bug-bounty #bug-bounty-tips #privilege-escalation #information-disclosure #access-control Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).