In order to prevent URL guessing for unauthorized users I will return a 404 error even if the URL exists. It's better to always return a 404 error page even if the call is to an API?? or is better to return a JSON with a 404 in case of and API call?? What do you suggest??
2 Answers
Well it is rather more friendly to return JSON if you API specifies that it returns JSON. If it doesn't specify either way, it probably doesn't matter that much.
In honesty, I generally prefer to return something useful and meaningful. For people, I would redirect to the login page. For an API, I would return an unauthorised message. Returning a 404 when the result isn't missing isn't terribly helpful. Of course, this is more a usability question than a security one.
If you want your app to be usable, return the correct/useful data unless it would leak something critical. If you want your app to be ultra-secure but less usable, best to not even return a 404, return empty data instead.
![](../../users/profiles/20102.webp)
- 7,092
- 17
- 23
-
Yeah, i agree that for API calls seems better to return an error message, now my concern is about the SPA routes (In my app is posible to directly GET any URL and it will be server rendered), it will be a security leak to let unauthorized users to know the app structure?? Let's say, if an unauth user enter to
/dashboard (Which is a valid route if authorized) and also enters to, let's say – DGomez Dec 06 '16 at 12:27/this_is_not_valid (which is a random route), in the first case it will redirect to login an in the other case it will return a 404 -
I would get the auth route to take preference. So when unauthorised, always redirect to login. That is easy to do server side. Check for auth first, if not, route to login page render. You can let ANY url be used then, it makes no difference. For auth'd users, have a default route that makes sense for your app. Maybe the home page, don't ever have 404 pages if you don't need them. – Julian Knight Dec 06 '16 at 23:22
One side of the coin is that you should not have security by obscurity, so there should be no need to hide valid actions behind 404 responses when the action cannot be called without authentication/authorization anyway. It's much nicer to just return something similar to 401 Unauthorized. On the other hand you're kind of right, this will probably allow mapping of your API, which you can also mitigate by for example rate limiting bad requests.
Your API structure is probably not that big of a secret anyway (it shouldn't be), consumers already know it, or if it's something like an API for your own mobile (or other) app, monitoring communications will quickly reveal calls to a potential attacker. If it's consumed by an SPA or a mobile app (something given to the client), reverse engineering the client also reveals the API.
Also if there is an authorization decesion on valid calls, it will probably be possible to use a timing attack to find out which calls are valid and which calls forge the 404 response, because the authorization decision will take some time.
So I think there is very little benefit in faking 404 on unauthorized but otherwise valid calls, and it makes the API less usable (but that's of course not a security question).
![](../../users/profiles/123361.webp)
- 1,163
- 7
- 11