The reason people use e.g. pin tumbler padlocks is either ignorance or cost. For software, implementing the correct stuff (that is, checking capabilities/permissions on server) requires about the same effort as doing it incorrectly (running trusted logic in untrusted environment, e.g. client).
My point is with the effort spent on "protection" you could have also implement real security instead. If you already had the incorrect implementation, sure, it requires more work to fix the whole implementation.
This "protection" will make attack a bit more complex but it cannot prevent it, unlike real security which requires doing the correct implementation.
(And yes, in case of digital security, you could argue that the attacker than brute force e.g. AES-128 encryption but physicists would then argue that the total energy needed would exceed the total energy of the Sun over its whole lifetime. That's much better level of security than the best mechanical lock you can get. And if you want high quality mechanical lock, the best options I've aware of are "Abloy Protec" and "Kromer Protector" safe lock. And of those, unmodified Abloy Protec has actually been picked in real life but that's really really hard. I know of three people in the whole world that can pick Abloy Protec.)
"will make attack a bit more complex but it cannot prevent it"
Then it serves it's purpose. I don't buy the argument "the effort spent on it would've been more useful elsewhere", because the effort to implement this was miniscule compared to the hundreds of hours already spent on implementing security measures on the API, and the hundreds (or maybe thousands) more that will take to make it technically impenetrable.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The reason people use e.g. pin tumbler padlocks is either ignorance or cost. For software, implementing the correct stuff (that is, checking capabilities/permissions on server) requires about the same effort as doing it incorrectly (running trusted logic in untrusted environment, e.g. client).
My point is with the effort spent on "protection" you could have also implement real security instead. If you already had the incorrect implementation, sure, it requires more work to fix the whole implementation.
This "protection" will make attack a bit more complex but it cannot prevent it, unlike real security which requires doing the correct implementation.
(And yes, in case of digital security, you could argue that the attacker than brute force e.g. AES-128 encryption but physicists would then argue that the total energy needed would exceed the total energy of the Sun over its whole lifetime. That's much better level of security than the best mechanical lock you can get. And if you want high quality mechanical lock, the best options I've aware of are "Abloy Protec" and "Kromer Protector" safe lock. And of those, unmodified Abloy Protec has actually been picked in real life but that's really really hard. I know of three people in the whole world that can pick Abloy Protec.)
"will make attack a bit more complex but it cannot prevent it"
Then it serves it's purpose. I don't buy the argument "the effort spent on it would've been more useful elsewhere", because the effort to implement this was miniscule compared to the hundreds of hours already spent on implementing security measures on the API, and the hundreds (or maybe thousands) more that will take to make it technically impenetrable.