1

I just wanted to ask if my concerns here are valid.

I am aware that it is unsafe for the API to return a stack trace. I have a similar, but less egregious, situation that I am trying to judge.

Is there also some standard regarding packaging up java exceptions into a 500 response? For example, sending back such things as "DataIntegrityViolationException," "NullPointerException," etc., but without the stack trace.

Worded another way, when an unhandled exception occurs, the exception name is sent back in the 500 response. There is no stack trace, but we can infer on the client-side if, for example, the request attempted to alter the DB in an invalid way.

I am currently warning my team against this and telling them that they should "whitelist" their server responses (i.e. only send content if you have a conscious reason for doing so). I just wanted to know if I am wasting their time with this.

Is this a good idea?

Or should it be more generic than this?

Improve this question
5
  • I am not sure that they are advocating it so much as operating off of inertia. They mostly want justification for spending the time to change what they have already made.
    – somexp12
    Commented Oct 27, 2020 at 17:14
  • Ok, then what you are wanting to know is if it is worth spending time to change. That's a little different than knowing what's standard. That's a risk assessment.
    – schroeder ♦
    Commented Oct 27, 2020 at 18:08
  • No worries. I was asking about that. Your answer was all I needed. This is a situation where the standard is a good chunk of the justification, if that makes any sense.
    – somexp12
    Commented Oct 27, 2020 at 19:01
  • Cool. I got worried that my name was going to be used in vain as you stormed into the next stand-up to say, "Schroeder said you all need to update the code!!" Standards are good, but implementing them needs to be done with risk awareness.
    – schroeder ♦
    Commented Oct 27, 2020 at 19:03
  • 1
    OMG, not my intention at all. I'm not trying to win any argument. Just making sure I am not introducing non-problems to be weighed against all the other concerns. Just needed the confirmation for myself.
    – somexp12
    Commented Oct 27, 2020 at 21:06

1 Answer 1

Reset to default
1

The standard in error handling to the client is to expose nothing about the inner workings and only provide what will be useful for the user to be successful.

Java error message contents do nothing to help the user. What you end up doing is exposing your code logic, which can be used against you by a malicious user.

OWASP's examples are simply to state that there is an error. And that's the standard. Any info beyond this needs to have a justification.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .