I hate this attitude. Yeah don’t give the user stacktraces on error but if you give it a meaningful headline and go in detail, experienced users will be able to deal with the problem if possible. If you go Microsoft-error of mystic ways you will have people Google “unexpected error e34566xce” and they will see that it has 10 possible reasons so you don’t know what even went wrong.
If your code gives attack surface by information about what went wrong maybe you should not even deploy anything. If your code needs to be secret to be secure your code is anything but secure.
Willing to bet that the backend that they are using doesn’t actually give any useful error messages.
Why use many words when few do trick but for system logs.
Would they surface that to the user anyway? That’s something to log, not to tell the client that xyz service failed because of error 123.
I hate this attitude. Yeah don’t give the user stacktraces on error but if you give it a meaningful headline and go in detail, experienced users will be able to deal with the problem if possible. If you go Microsoft-error of mystic ways you will have people Google “unexpected error e34566xce” and they will see that it has 10 possible reasons so you don’t know what even went wrong.
There’s nothing a user is going to be able to do if this is a problem with the backend. The person I replied to did specify backend, right?
Thin line between giving useful error messages and more attack surface.
If your code gives attack surface by information about what went wrong maybe you should not even deploy anything. If your code needs to be secret to be secure your code is anything but secure.
Not code but internet. A often seen error is letting Appache/Nginx display their name & version in 403/404 pages. First step in planning an attack.