When Username Enumeration Isn't a Vulnerability
Not every report I’ve filed has held up, and I think that’s worth writing about as much as the ones that did. This one is a case where the triage call was right, and the more useful post is explaining why.
The finding
The /api/courses API endpoint on a course/training platform returned a username field directly in the response, no authentication required. Searching the raw response for "username" turned up a full list of enrolled users.
On its own, that’s the textbook shape of a username enumeration report:
- No brute-force needed, just visit the endpoint.
- Confirms which usernames exist on the platform.
- Classic writeups list this as a stepping stone to credential stuffing, targeted brute-force, or phishing.
The triage response
The report was marked Not Applicable:
“All of them are public information”
That one line is the whole story. The platform in question is a public training/course hub, course rosters, cohort listings, and participant names are meant to be visible as part of how the platform works. There was no access control being bypassed, because there was nothing access-controlled to begin with.
Why “enumeration” isn’t automatically a bug
The enumeration bug class only has teeth when the enumerated data is supposed to be private. Compare two shapes of the “same” finding:
- A login form that returns a different error for “user not found” vs. “wrong password.” This is a real bug the system leaks account existence that was never meant to be exposed, and it directly assists credential stuffing against a specific, real account.
- A public course roster returning enrolled usernames. This is the platform working as designed. If the product already shows a public leaderboard, a public cohort list, or public profiles, then “I can list the usernames” isn’t a disclosure, it’s the feature.
The technical mechanism looks identical from the reporter’s side (an unauthenticated endpoint returns usernames), but the actual security question is always the same: was this information private before I looked at it? If the answer is no, there’s no confidentiality boundary being crossed, and enumeration reports built on that endpoint won’t survive triage, correctly so.
What I’d check first next time
Before filing an enumeration report, it’s worth spending five minutes checking whether the platform already exposes the same data through an intended, public feature, a leaderboard, a public profile page, a certificate verification page, a participant directory. If it does, the “vulnerability” is really just a second, less convenient way to view public data, and it’s going to get closed as Not Applicable for good reason.
Takeaway
The triager (as always) is right, the usernames genuinely weren’t secret. The value in writing it up isn’t “I found a bug,” it’s the reminder that impact comes from what data was protected, not from whether an endpoint technically discloses something.