I am annoyed by (but respect) APIs that take it a level further and don’t even give you a 403 to say you’re unauthorised, they just give you a 404 because anything else would acknowledge that the resource you requested actually existed
I don’t respect them because most instances a 403 is more than adequate for your security. The only time I agree with having a 404 over a 403 would be file-specific pathing, but realistically the entire file directory should be a 403 instead of a 404, And then if the user is authorized to access the resource(but it isn’t there), then it gives a 404.
Yea, it doesn’t matter too much in most instances, but there are times when it might, especially if the URL itself has some meaning embedded in it. For example if part of the path is a SHA sum of some content, which is fairly common, it might be bad to allow someone to determine if that resource exists
I’m not sure. I was actually asking. And I’m not even sure enough to tell if this is a joke reply you’re making or not. Lol.
I just assume the process is to start a general session. Rather than accessing the request to the resource directly.
So, I guess it would be abstracted a bit though. The user COULD be successful at starting the session. Get a success response to redirect to the resource they are trying to reach AFTER the session starts. Then once they are logged in their privileges are checked on that resource. Either returning an unauthorized response or the actual content.
So, I’d guess this is (at minimum) a two step process. Though from a user perspective they just login and get the resource.
If the login fails it’s just a single response. I’d guess for security just a 200 response but with no session token or response.
Honestly, I’m just typing this for my brain to try to remember the small amount of work I did with Redfish and RESTful stuff awhile back.
But, you are right. There isn’t a reason to give the user html error codes that can tell them anything more than they should know. Without a user session or without user privileges it’s just telling users more than they should. Redirecting to a 404 page with the same generic response is probably best practice. As long as it’s consistent.
Any further “helpful” information in that error message would be a security issue.
I am annoyed by (but respect) APIs that take it a level further and don’t even give you a 403 to say you’re unauthorised, they just give you a 404 because anything else would acknowledge that the resource you requested actually existed
I don’t respect them because most instances a 403 is more than adequate for your security. The only time I agree with having a 404 over a 403 would be file-specific pathing, but realistically the entire file directory should be a 403 instead of a 404, And then if the user is authorized to access the resource(but it isn’t there), then it gives a 404.
But if there is no resource, how can the system know whether they are authorized? 403 it is.
Yea, it doesn’t matter too much in most instances, but there are times when it might, especially if the URL itself has some meaning embedded in it. For example if part of the path is a SHA sum of some content, which is fairly common, it might be bad to allow someone to determine if that resource exists
Wouldn’t unauthorized only be meant for AFTER a login is successful?
Like, the user should have to have an active session first. Maybe you’re just talking about that case though.
Maybe I meant unauthenticated. What is this, mandatory cybersecurity education!?
I’m not sure. I was actually asking. And I’m not even sure enough to tell if this is a joke reply you’re making or not. Lol.
I just assume the process is to start a general session. Rather than accessing the request to the resource directly.
So, I guess it would be abstracted a bit though. The user COULD be successful at starting the session. Get a success response to redirect to the resource they are trying to reach AFTER the session starts. Then once they are logged in their privileges are checked on that resource. Either returning an unauthorized response or the actual content.
So, I’d guess this is (at minimum) a two step process. Though from a user perspective they just login and get the resource.
If the login fails it’s just a single response. I’d guess for security just a 200 response but with no session token or response.
Honestly, I’m just typing this for my brain to try to remember the small amount of work I did with Redfish and RESTful stuff awhile back.
But, you are right. There isn’t a reason to give the user html error codes that can tell them anything more than they should know. Without a user session or without user privileges it’s just telling users more than they should. Redirecting to a 404 page with the same generic response is probably best practice. As long as it’s consistent.
While true most of these websites expose valid usernames in other places