Managing Error Responses

Do you want to provide your customers and developers with an error response that gives them enough information that they can figure out what the issue is without having to call you for every little thing?  Of course!
Do you want to provide attackers with actionable data they can use to more intelligently probe your system for weaknesses?  Of course not!

So the question becomes; where do you strike the balance?

On one extreme if you do not set the error response level and do not set a custom message then your customers receive an XML stack trace of your policy with L7 elements all through it.  This is really your worst case scenario because attackers now know what system your running and what parts of the policy they got caught at including failures within 'At Least One' folders and on the other side it is likely meaningless to any of your developers or customers that do not already have access to a Layer 7 system.

On the other extreme you can set the 'custom SOAP Fault Response' to 'Drop Connection', such that any time a request results in a policy violation including route failures due to returned HTTP error codes, will cut off customer and attacker alike giving them nothing to go on.  Of course you will get many more calls from developers trying to make requests to your system.

There is more than one way to split the difference.  Your development environment, which should be less accessible, can surface more detailed error responses.  While in production it is reasonable to provide some generalized (and standardized) error responses.

HTTP error codes are standard enough to tell your customers what is wrong while being general enough to not give attackers very much to go on.  SOAP in particular has a standard format for error response messages and JSON is so open you can pick whatever schema you want, just try to be consistent for the sake of you application developers' error handling.

Your first consideration is protecting your Layer 7 system by masking any error response from revealing policy details or the fact that it is a Layer 7 system.  The next is to protect the back-end systems (really that's most important, but you can't protect them if you can't protect yourself).  To this end it is generally undesirable to forward errors directly from the back-end to the requester.

More than likely you are using multiple authentication schemes throughout your environment, but if you return a 401 instead of 403 when you do not find the expected type of credentials then attackers can determine what type of credentials they need by trial and error.  By checking for the existence of other types of credentials before deciding which of these HTTP codes to send you can keep attackers snow-blind while still giving your customers a hint enough to tell when they are sending the incorrect credentials versus not attaching their credentials at all.

I parse the routing failure messages from the Layer 7 audit log and then represent it as a 400 or 500 HTTP code depending.  I like to represent policy violations in request and response validation as HTTP 400 and 500 codes respectively.  I also like to take a bit of liberty with the interpretation of the HTTP codes, such that when my customers tell me the error they are receiving I immediately know what the issue is, but if an attacker were to look up the meaning it may not quite make sense.  After explaining the meaning to my customers once or twice they catch on because it is consistent and symbolic.

While the help files contain a list of the Layer 7 error codes, they do not contain a list of messages for code 4042.  For which I have mapped 14 messages to date.  See the post immediately following this one for a template you can use to get started.