Forum Discussion
I'm sorry to revive this old thread but the issue is being revisited by our team right now.
Of course leaking sensitive details is a big problem and must be avoided, but that doesn't mean that http status code 5xx are leaking such details.
Applications should be programmed and/or configured to catch unexpected errors and transform them to 5xx responses with some opaque content allowing to refer to the issue in some way so the event can be related to appropriate log entries to be diagnosed and fixed.
But the 5xx status code should reach the client so it can act accordingly.
Otherwise the client is tricked receiving a 200 response with a completely unexpected content which causes lots of headaches.
I am guessing that by 200 response 'tricking' your client app you mean ASM's default blocking response page and you are probably talking about an AJAX app or a mobile app using REST. The 200 response code for ASM blocking page is just a default setting which you can change - it is not hardcoded. It appears that in your case you should have a customized policy and custom response. For example you can change the response code to 403 which seems to work well with most apps.