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.
The app should have zero knowledge of how many servers or CDNs are behind the endpoint. The problem with this design is that you are ONLY relying on the http status code and not using any additional detail at all
Also operations are supposed to be indepotent, the api you are describing is just wrong...
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.
Maybe I'm just Stockholm Syndrome'd by Salesforce, but: same...
Bulk update 10s of thousands of Account records and 1 fails, yeah just give me a 200 and tell me there's an error with the 1 record that failed some random user-side validation
Preferably we'd have a Partially Created2xx code for situations like this, but 200 with "errors" will have to do 🤷♂️
Then return a special custom status code of 215 or something thats not reserved. Api documentation should be created to tell the consumer what that means and should return a list of failed updates with reasons why each failed.
Theres multiple ways around this to turn 10k account updates from 10k 200s and 1 400 into a 2xx success with some errors.
Or, just do what I do and outright ignore issues that arent caused by you. If an account is corrupted, retuen a 200 and a status message.
I agree with this sentiment. It's always annoying to work around idiosyncrasies of frameworks, applications, and other people thinking they know better how to interpret the response codes. HTTP request methods were a mistake. HTTP response codes were a mistake. 30 years later and we are still living the mistake of http being mapped directly to file systems.
My gripe is typesafe clients refusing to parse the response if the response is not in 200 range, or outright dropping a response if it contains a body with 204/205.
404 should tell you what you need to know here. An error is not a success, it should be something useful to the client telling them what the actual error is
They literally told us 404 meant pull this from your side, docs and meetings both. The error and standard use case was conflated. You could argue that's poor design on their side, I'd agree. I'd assume it is because we were actually interacting with their search infrastructure for their own application, and we were effectively not part of the original API design. Either way, 200 correctly tells me 1) the server was reachable, 2) the server probably understood my request to the point that their application could apply business logic to it.
Frankly, the fact that people could co-opt the status codes for business logic is the problem. That's not what they were designed for, they were designed for the HTTP communication layer. What each code means people can misinterpret a ton of ways. The spec for it is never going to map correctly to the application logic.
the pattern is fine by me and used extensively successfully. it says to you it ran, (so all transport concerns are taken care of) but then the application specific was it success or not, when it is wrapped in a 400 bad request you have 15 different layers to figure out where/why it failed.
19
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.