Introduction
When building a web application, you typically add authorisation checks to ensure that users can only access resources they...
For further actions, you may consider blocking this person and/or reporting abuse
You are not fixing anything by changing the http status. The only thing is that you are creating more problems for yourself and your website users.
You are never going to stop logged in users to share authenticated urls, so even if you use a 404 status there are always other means to find out urls.
This is just bad advise.
Hey! One of the things I mentioned towards the end of the article is that it can make it harder to debug errors and that it can affect user experience. I also mentioned that your application is likely still susceptible to timing attacks, too.
The article isn't related to users sharing authenticated URLs, but rather as a way to reduce the likelihood of malicious attackers trying to find resources. Of course, this is one of many approaches that can be used alongside other techniques to improve your web app's security. It shouldn't be relied upon solely, as more sophisticated bots can circumvent this 🙂
You mention the solution is easy to circumvent, so why bother with the extra trouble it brings for you? It is like hiding a house key under a flowerpot near the door. It is the first place thieves will look.
As I mentioned in the original post and my comment above, it's not something you'd rely on solely.
For example, let's take a private GitHub repository (we'll say it's github.com/example/super-secret-repo). If we tried to visit that URL as a user who doesn't have authorisation to view it, a 403 response could be returned. But by doing that, we've just confirmed the existence of that repository.
So, in this particular use case, we might want to opt for a 404 response instead. Now, a malicious user won't know whether the repo exists (purely based on the status code).
That will be helpful to stop people who are manually trying to probe for that resource in their own browser (by typing the URL in the address bar). And it will also stop basic bots that only check things like the status code to determine if the repo exists. However, if the bot is using a timing attack, it'll be able to make a pretty good guess as to whether the repo exists.
So at this point, you can add some code to your application (for example, the
Timeboxclass in Laravel: laravel.com/docs/12.x/helpers#timebox), to reduce the likelihood of a successful timing attack. This can then also be paired up with rate limiting too.Now, through a combination of different approaches, it makes it much more difficult to determine whether the repository exists or not.
So, it's acting as a belt-and-braces approach. And of course, there are many times when it's just not needed, and in most cases, you likely will want to just return a 403. So it's a case of weighing up the pros and cons for each particular use case 🙂
You may not use this technique, it's your choice. So do I. However, people may do.
For example, GitHub returns a 404 response when you try to access a private repository that you are not the owner or a participant.
Yeah, as you say, it's a technique that's available. But it doesn't mean you have to use it. And there are definitely places where it wouldn't make sense to use the 404. So it's all down to the use case and feature, and deciding which status code would be most suitable.
I think your GitHub example is a perfect use case. By returning 403 for a private repository, we'd be confirming the existence of the repo. Whereas, with a 404, you wouldn't know whether it exists or not 🙂
And what is about using 401 (Unauthorized) for any request that needs authorization. Returning 401 when you don't authenticate OR when you authenticate, but don't have the rights to access that ressource. And only return 404 when you would have the right to access it, but it doesn't exist.
That way you can't really see if you are allowed to acces, can't prove you are allowed to acces, or if something isn't there. While on the other hand, if you are allowed to acces and it's not there, you will know (404)
Super puas, estetiknya bikin kagum 👌JO777 bikin ketagihan