Our consulting company has received a VAPT from a consulting company on behalf of a financial customer.

The application has an HR/group management module.

Normally employees are created by an asynchronous process, but in case this fails the application's admin should have access to UI and create a user along with their line manager.

There is API GET /api/v1/employees/lineManagers to list users that are eligible as line managers. And API POST /api/v1/employees to create a new employee. And there is API GET /api/v1/employees that basically lists all employees and is required by the management UI,

In order to create a new employee, one has to POST several parameters:

    "userid": "",
    "name": "",
    "surname": "",
    "lineManagerUid": "",

Now, if the user ID of the line manager is not existing or is not enabled as LM, the application will return 404 error because of Java's Optional.orElseThrow (from a programming perspective, we query the database for the user and check that it has all flags).

From a security standpoint, I'd like to understand why this is considered a vulnerability. Consultant say that one can alter the JSON payload as soon as they find a valid user ID (rate limiting is done at API gateway, so outside our scope), so that a 202 response means that the line manager ID is valid and 404 that it doesn't exist.

I wonder why they are focusing on that because users can be listed by requirement, you don't need to hammer the POST api to enumerate the possible LMs as soon as you can invoke the authenticated GET and obtain all users.

I don't also think that returning 400 other than 404 will fix the issue, as user enumeration is triggered when you can determine the existence or not of the targeted user.

Since the application admin can nominate another user as Line Manager of new employee, how do you fix the user enumeration vulnerability when you actually need to enumerate them?

  • Are the authorization requirements different between GET /api/v1/employees/lineManagers and POST /api/v1/employees? If anybody who can attempt to create a user could already view the list of line managers, then leaking who is or is not a line manager means... nothing at all, and certainly isn't a vulnerability unless at some future point those privileges diverge. Given that situation, erring on the side of informative errors is better, IMO. It doesn't even sound like this is particularly sensitive information...
    – CBHacking
    Mar 4 at 20:52

1 Answer 1


It's the age-old discussion between "Create an API-interface that provides proper error messages" vs. "Don't let an attacker know what he did wrong."

This is a classic dilemma for all "Information Leakage" Type of vulnerabilities, so it comes down to a business / GRC decision. This decision could be nased on:

Is the risk of a wrong implementation higher because the API does not respond properly or is the risk of an attacker knowing that a certain line manager does not exist higher?

Does it rise implementation cost for all API consumers?

Is the POST-request also authenticated?


Personal Opinion: For me, this finding looks like a very narrow-minded vulnerability rating that is discussing this for the sake of having something to discuss.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .