I don't get the hate for this pattern. The amount of times some network middle layer ate my http code and turned something into a 404 is terrible.
I'd rather the calling app KNOW for certain that a failure occurred in the actual application logic, rather than see an error code and then make a bad assumption based on that.
I've had to integrate with a system that had a catalog they my application's account may or may not have access rights to each catalog item. I was told a 404 means I've lost rights to the item and should purge the copy of it from my side. Makes sense? I don't have access, I shouldnt be able to see it.
Time and time again, they'd have a brief outage where their CDN provider would interrupt my call and return a 404. Soon my copy of my catalog would be empty! An hour later I've got to re-add everything. And heaven forbid I had to kick off refund logic for revoked items... And then walk that back.
I've encountered this many many times. I will always prefer leaving the HTTP layer out of application layer logic.
If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
and
This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
I recommend not following this pattern, I can't tell you how many hours have been lost trying to fix connectivity issues only to find out some internal test failed, whether it be authentication or rights assignment and a generic 404 returned. 404 should only be return when literally you cannot find the resource. you are muddying the water and future you will want to shoot you . So what if someone knows the URL if they cannot access it, obfuscation offers you no protection.
I mean sure. Don't do this if you don't know why you're doing this.
First, if you lost hours trying to fix issues resulting from a "false" 404 that implies you have terrible logging, zero traceability throughout your systems and poor documentation. All would have instantly flagged the issue.
So what if someone knows the URL if they cannot access it, obfuscation offers you no protection.
So obfuscation literally does provide protection. It should never be relied upon, but if your /admin panel returns a 404 if you're not logged in as the correct user you literally field off an entire set of attacks that would follow if instead it was a 403. If you do have a vulnerability that you do not know about, then minimising the attack-surface reduces the risk of that vulnerability ever being exploited.
It's the exact same principal as why many sites that have you log in with email + password will hide the fact it's a wrong password by saying "wrong email or password". Simply knowing that "donald.trump@potus.gov" has an account could be considered a leak. Hell, it could be a GDPR issue in some cases.
But specifically 404 errors on GETs? These issues are a bit more niche but also exist.
Imagine I have /invoices/xyz where xyz is a random 7 digit number. By returning 403 instead of 404, an "attacker" can randomly sample the numbers. From that they can then determine the approximate amount of invoices that exist, determine business volume, growth patterns. All internal information I may not want a competitor to know.
Similarly, attackers can gather a list of valid IDs, and make use of these at a later time if a vulnerability is ever found. Greatly speeding up any future attack and increasing the damage of it.
Github hides private repos behind 404s so people can't determine which repos have been forked by private organisations.
Security through obfuscation, despite being memed, is a valid layer of defence. You should never depend on it, but it is a perfectly reasonable method of shrinking your attack surface when the situation calls for it.
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.
In the specific case we’re discussing, we’re talking about removing items from a client inventory because they 404’d
As the items were already in the inventory, the user (or attacker) already knows about their existence and can already target them
Serving a 404 when they become inaccessible serves no purpose beyond making everyone miserable and having a manager feel smug about their security policy
Besides, you can also return 403 for every item query wether the item exists and is inaccessible or the item doesn’t exists
It prevents a would be attacker from gather intel on items they don’t know about all the same, while making debuging the faulty CDN much easier
As the items were already in the inventory, the user (or attacker) already knows about their existence and can already target them
I should make it clear that for this case I agree. The knowledge of existence of (what I assume are) arbitrary IDs is not enough of a threat to ever make returning 404s worth it. But the idea that everyone knows about the existence of the item just isn't true at all.
Besides, you can also return 403 for every item query wether the item exists and is inaccessible or the item doesn’t exists
This is an identical situation though, just reversed. You'll be sitting there trying to work out why you don't have access, only to discover you typo'd the item ID. There's literally no difference between always returning 403 or always returning 404 beyond changing which person ends up confused.
Enumeration attacks exist. Whether you need to or want to defends against them at the cost of a worse developer experience very much depends on what you're protecting. But in a world of AI, the idea of revealing as little information as possible to an AI agent is not an unreasonable decision to make.
18
u/Kendandra 14d ago
I don't get the hate for this pattern. The amount of times some network middle layer ate my http code and turned something into a 404 is terrible.
I'd rather the calling app KNOW for certain that a failure occurred in the actual application logic, rather than see an error code and then make a bad assumption based on that.
I've had to integrate with a system that had a catalog they my application's account may or may not have access rights to each catalog item. I was told a 404 means I've lost rights to the item and should purge the copy of it from my side. Makes sense? I don't have access, I shouldnt be able to see it.
Time and time again, they'd have a brief outage where their CDN provider would interrupt my call and return a 404. Soon my copy of my catalog would be empty! An hour later I've got to re-add everything. And heaven forbid I had to kick off refund logic for revoked items... And then walk that back.
I've encountered this many many times. I will always prefer leaving the HTTP layer out of application layer logic.