Exposed Endpoints Lead To Leak PII

Exposed Endpoints Lead To Leak PII | by 1sherlok - 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 Exposed Endpoints Lead To Leak PII Hello everyone, I'm Sherlok, and today I'd like to share a story about how I discovered exposed endpoints in an API that led to a leak of… 1sherlok Follow ~3 min read · March 22, 2026 (Updated: March 22, 2026) · Free: Yes Hello everyone, I'm Sherlok, and today I'd like to share a story about how I discovered exposed endpoints in an API that led to a leak of PII and the internal folder structure. Let's begin: While doing some routine recon, I started exploring API endpoints and checking how they behave with different authorization states. Nothing fancy -just sending requests, observing responses, and looking for anything that behaves differently than expected. I sent a simple GET / request just to see how the server responds-and I got a 200 OK with a somewhat unusual message: "redirect to /admin" That caught my attention. APIs often protect "data endpoints" but forget about "asset endpoints" like files and folders. Since this looked like Directus, I knew it usually exposes /items , /files , /folders , so I started testing those. At first, everything looked fine -most endpoints were properly restricted and returned 403 Forbidden , which is exactly what you'd expect without authentication. But then I tried a couple of different endpoints: /folders /files And that's where things got interesting. Instead of a 403 , both of them returned 200 OK . And not just empty responses-they returned actual data. Real files. Real users. Real email addresses. At that point, I had access to sensitive data returned directly from the API responses, including: File metadata Internal folder structure User identifiers Even email addresses (PII) Full names of users That's when it became clear that these specific endpoints were not protected like the others. How It Worked The issue here is pretty straightforward. The backend failed to properly validate authentication and authorization for sensitive CMS endpoints. In other words: Invalid tokens were accepted The server did not verify whether the requester had permission to access this data So instead of blocking the request, it simply returned internal metadata. Impact This kind of issue might look simple, but it has serious implications. An attacker could: Enumerate users via exposed email addresses Map internal CMS structure Gather metadata for further attacks Perform targeted phishing or social engineering It also introduces: Privacy risks Compliance concerns Increased attack surface for more complex exploits And the most important part -no authentication was required. Root Cause (in plain terms) This wasn't a complex vulnerability - just a classic access control failure: Sensitive endpoints exposed publicly Missing or broken authorization checks Invalid tokens treated as valid Overexposure of internal metadata (including PII) Basically, the system didn't verify who was making the request before returning sensitive data. Fix / Recommendation To properly address this issue, the backend should: Restrict /folders and /files endpoints to authorized users only Validate all authentication tokens correctly Return 401 or 403 for invalid or missing credentials Review CMS role permissions (especially public/unauthenticated roles) Remove sensitive data like email addresses from metadata where possible Disclosure Note I responsibly reported this issue with a clear proof of concept and minimal testing. Issues like this are a good reminder that security doesn't always fail in complex ways - sometimes it's just a single missing check in the right place and that's all it takes to expose everything. And those are often the most dangerous ones. Anyway, that's it for this one. Happy hacking 👾 #bug-bounty #bug-bounty-writeup #bug-bounty-tips #cybersecurity #api 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).