In my Spring MVC 3 application, I am following REST patterns and lots of logic is based on HTTP status codes. For instance 500 defines a server error. But OWASP modsecurity says not to expose this status code.

I don't understand why a 500 status code would be bad? I see even Google showcases 500 properly.

  • This is somewhat a matter of opinion. The most common approach - and what I favour - is to return a 500 error code, but include no technical details in the error message.
    – paj28
    Oct 4 '16 at 10:27
  • it's talking about overly-revealing 500 pages that dump out a stack trace with file paths, app source code, variable values, and the like.
    – dandavis
    Oct 4 '16 at 17:37

An error 500 indicates that the server had an internal error. It normally means one of two possibilities:

  • either a component is down - ok, the error will disappear as soon as it is up again
  • or an exceptional condition is not correctly processed by the application

The occurence of an error 500 should always be followed by an action: if a component was down, it must be repaired or restarted, and if an exceptional condition was not filtered, the application needs a fix.

A problem occurs with applications that do not process exceptional conditions, and are poorly supervised and maintained. If an attacker sees an error 500 that consistently happens in certain requests, it is an indication that the application could not process it, and did not process the error condition either. Maybe a slight variation could make bad things happen...

But simply replacing the 500 code with say a 400 is not a true solution: it only hides the real problem. If I was doing a black box penetration test (with no access to code), I just would not rely on the value of the error code and try all known weaknesses, so hiding an internal 500 with a 400 would not protect the application. And I really believe that serious hackers will think the same...

In a professional world, the 500 errors should be analyzed, and when caused by an non processed exceptional condition, a ticket should be filled to the developper team. For an internal application, an error 500 should mean (explicitely or implicitely) this is an unexpected error, please contact support


servers errors generally give overall view of how far the attack was successful on server. like if its 403, it shows that specific authentication was successfully blocked by server (means server handled certain illegal activity quite well), but when server throws 500, it means it was not able to handle certain error, hence it got confused , as a result, giving hacker chance to put more effort in exploiting 500 related error, where he can dig more deeper to penetrate inside server.

In short, 500 errors can be dangerous, as they are only thrown when something unhandled occurs, and users should not see its result or output it generates.(that status or result can be effective in penetrating deeper into server)

  • How would a UI convey that something bad happened to a real guy ? There has to be some distinguishing factor, then in that case any distinguishing factor would be enough for hacker..no ? Oct 4 '16 at 5:48
  • obviously hackers can reach to the api or http call made behind the UI, from there they can get the status code. Oct 4 '16 at 6:38
  • Yes, my point is how to then show some catastrophic message on UI if there is 500 in backend ? Ofcourse, we cannot show success message. Oct 4 '16 at 6:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.