In a few occasions, pen-testers asked me to avoid the use of detailed HTTP return codes that could reveal information to an attacker.

For example, they said that it is wrong to return a 404 when the resource does not exist because this helps to enumerate the existing resources.

All the articles I have read about best practices for the development of APIs, suggest to return meaningful error codes and in particular they stress that a 404 should be returned when the identifier of the resource in a GET does not correspond to an existing resource.

Isn't this behaviour a security vulnerability ?

See HTTP Status Codes as an example

  • the 404 status is used to trigger a lot of error-handling routines in JS ajax; removing that will cause to you have to fork in the success handlers to make sure they really were successful... – dandavis May 8 '17 at 4:41
  • It COULD be a security vulnerability, like leaking your growth info etc. as well, If you care about resource enumeration or leakage you can use random UUID's. But for most of the things I hardly think this would be a problem. Mind that before enumaration they should have a valid authentication otherwise they get 401 or 403 if you do authorization, so this scales down the vector of attacks in my opinion. – EralpB May 8 '17 at 8:02

If you have this Y-problem,

it is wrong to return a 404 when the resource does not exist because this helps to enumerate the existing resources.

then this means you have this X-problem:

Resource enumeration should be prevented.

This in turn might affect all resources or unauthenticated resources only. In other words you might be able to mitigate the problem by requiring authentication before asking for a given resource.

Otherwise, you could make said resource difficult to guess, and implement some kind of scanner detection (simply storing what resources get 404'ed by which network for some time could be enough. You could perhaps offload the problem to an installation of fail2ban).

The problem as stated makes little sense because you cannot return a valid resource if an invalid one was requested - in general, you can't make up sensible, believable resources out of thin air! So there will always be a way to distinguish between resources that exist and resources that don't. Granted, supplying the information in a HTTP status header makes things simpler for the attacker, but it also makes things easier for you.

In some cases you might be able to synthesize a nonexisting resource. For example say you offer something akin to an avatar service. Then /users/lserni/avatar.png could return my picture, while /users/someoneelse/avatar.png could return a random picture generated using "someoneelse" as random seed, so that the same someone else always gets the same PNG back. But as you see, this kind of approach requires specific domain knowledge, there can't be a one-size-fits-all rule.

  • You are right. My question is incorrect. I will not delete it because your answer is interesting. – Marco Altieri May 7 '17 at 20:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.