>> This is logic that says that SQL Injection is fine, so long as the HTTP request bearing it elicits a 200 response.For my tastes, this is actually a reasonable configuration of things.
Nobody is forcing you to use HTTP. If you decide to, and you provide access to your database via HTTP, and you allow me to submit a payload which makes changes you don't like, you are welcome to stop me and issue a 403. It's your database, after all.
Nobody is forcing you to use a door. If you decide to, and you provide access to your home via door, and you allow me to open the door and do things you don't like, you are welcome to stop me by locking the door. It's your house, after all.
You cannot say that issuing a 403 instead of a 200 is OK but turn around and say unpermitted access (what should give a 403) is okay so long as you are given a 200 in response, even if by accident.
If door is locked > return 403 else return 200
The only difference is that the 403 and 200 are implicit with the door being locked or not, rather than an explicit response from door since door is incapable of giving a response (unlike server). Although both server and door are handled by a human.
The shared point of failure is how the human configured the server//door to return a 403/200//unlocked/locked status to individuals other than itself.
Forgetting to lock your door, failing to set -NOACCESS for ${Robber}, is exactly like forgetting to disable the -READ flag for ${User}. Therefore, the configuration is not reasonable.