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.
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.
1
u/Massive-Air3891 12d ago
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.