Why do people continue to ask me why I'm not just sending any - ANY - error/exception message in full length to the user.

Am I going nuts? You can't tell me that this is a good idea right?

Because the laymen wouldn’t understand it and feel intimidated.
Or worse, go tell everybody it’s completely broken and shouldn’t be used..

For debugging, delegate to an error/issue tracker

@lotd we have tracing, metrics and logging in place

I usually don't always give a straight answer because I want to make the person asking think for themselves. Security never seems to pop up in their mind

@alexbrooklyn know that kind of person

that's a hard erect NO security-wise

@alexbrooklyn Just send "Something went wrong. Please try again later." message and call it a day.

@ostream You assumed it was for both consumers/devs. I didnt mean that way. OP was getting bombed from the customer side so that is why I said that. Ofcourse, the dev should log it internally to investigate it later.

@ostream In those cases, the dev should pass them a reference ID (or something that identifies the fault uniquely) and show it to the user. Something like this -> Something went wrong. Please try after sometime. (REF ID - {REF_ID}).

The user can then forward the ref id to the customer support and that case will be taken care of.

The whole point of putting a generic message is saving the customer from being shown unnecessary information about the fault that they probably wont understand anyway.

You are a dev that's why u want to see exactly what went wrong. But you need to realize half the world is stupid.

I don't care about ux here, security is the main concern. An error code would indeed be more appropiate, but we have tracing so no need

@ostream that isn't what I'm ranting about, but I agree with that

Security on one hand.

On the other hand it's about leaking internals.

Which has to do with security, but more with architecture.

The worst is leaking some libraries exception unfiltered to the user. By library I mean a foreign library you depend on, e.g. the database / form layer.

Story of "howto break a whole application by leaking improperly encoded data into an endpoint" TM.

Many libraries print stack traces or other gnarly details - which might contain erroneous data, which is then passed onto another API endpoint".

Which can lead to an interesting domino effect in case of micro services.

Especially when the poo poo devs decided to catch an exception and pass the exception along to the callee, so that you then have not only one endpoint failing but every endpoint... Which might be quite a lot in case of microservices.

The logging server doesn't like to be bombed, either. Especially not by high frequency APIs playing exception of doom ping pong.