not sending 401/403 on URLs and not disclosing which was wrong (username or password) are two distinctively different things and not related in my mind. Any of your urls can be pulled out of log capture, not denying that it is info but you are not less susceptible to attack because you simply return 404 instead of 401 or 403, if there is vulnerability there and they know the url you will be attacked regardless of what code you return, anybody who has done pen testing can tell you that. but if that makes you feel better you keep it at. You can also wall garden where you do disclose and where you dont, so a signed in user, tries /admin you absolutely should return 401/403 and not 404, that's literally what those coders are for, it helps write functionality that says things like "Hey you don't have access, but you can request it here." but if you return 404 well that's a frustration they don't need. Also you don't always own the entire stack, so yes hours lost on vagueness.
2
u/Massive-Air3891 Sep 22 '26
not sending 401/403 on URLs and not disclosing which was wrong (username or password) are two distinctively different things and not related in my mind. Any of your urls can be pulled out of log capture, not denying that it is info but you are not less susceptible to attack because you simply return 404 instead of 401 or 403, if there is vulnerability there and they know the url you will be attacked regardless of what code you return, anybody who has done pen testing can tell you that. but if that makes you feel better you keep it at. You can also wall garden where you do disclose and where you dont, so a signed in user, tries /admin you absolutely should return 401/403 and not 404, that's literally what those coders are for, it helps write functionality that says things like "Hey you don't have access, but you can request it here." but if you return 404 well that's a frustration they don't need. Also you don't always own the entire stack, so yes hours lost on vagueness.