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 🙂
It is not because a big website is doing it, it is a good practice.
The http statuses are one of the foundations of a website, so I don't understand why people want to mess with it. You are not going to build your house on mud.
Did I say "it's good practice"?
Again, I said "it's your choice".
You needn't to use it. However, others may do for their reason.
I completely agree : You're much better off using obfuscated ids and a rate limiter so that enumeration becomes practically impossible, rather than returning 404 codes instead of 403 (which as pointed in the article are still vulnerable to timing attacks anyway unless you go to great length to avoid that).
That said, sometimes you're not doing things to actually improve security, you're doing things to get approval from whoever is auditing your product, and some security auditors consider this is "good practice". So yeah... I just make everything a 404 and then read the logs when I need to know why I can't access a page.
Absolutely, using obfuscated IDs and rate limiting are also huge help too. As I mentioned in the article (and some other comments), you wouldn't rely just on changing the status code because that wouldn't provide much value; instead, this is just an extra approach you can use alongside other security features.
And, of course, as I mentioned in the article, it doesn't make sense to return 404s everywhere for failed authorisation checks. In most cases, you would return a 403, but the 404 can be useful in certain places (especially when partnered up with some code to prevent timing attacks).
For instance, using my private GitHub repository example. The repo names are human-readable (e.g., github.com/example/super-secret-repo) so ID obfuscation can't be used. But if someone tried to visit this URL, returning a 403 would prove the existence of this repo, whereas a 404 wouldn't.
So there's a time and a place for using it. And I'd never suggest using it by default; just if the feature or use case would benefit from it 😄
Super puas, estetiknya bikin kagum 👌JO777 bikin ketagihan
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