Is exposing exception information in web service a security risk?

The API should not expose any internal information, i.e stack traces or similar. As you really noticed they might leak information which might be used to attack the implementation.

Moreover they are usually only relevant for the developer of the API and not the user of the API. These users expect proper error messages anyway and not some strange message where they would need to ask the API developer first what this means and the developer would need to look at the source code. So this might be less a security issue but more a usability problem of the API if you just throw the stack trace to the user instead of something meaningful for the user.

Usually, there are two kinds of exceptions:

• Expected exceptions, like invalid input values; or authentication failure; or asking for non-existing object. So you can (and should) be prepared to deal with this kind gracefully, with descriptive and documented error code and message. There is no point of stack trace in this case.

• Internal (or unexpected) exceptions: unavailability of database; insufficient memory; bug in your code leading to NPE. There is also no point in stack trace for API user. You (as a developer), however, have interest in such stack traces. For the most cases, user itself can't solve such problem, so he must contact the developer. You can attach encrypted stack trace to a generic "sorry" message, so you as the developer can resolve user problem more easily:

It is a problem of usability vs. security.

• An API, specially a REST one, should be friendly, self-documented. This includes giving friendly errors indicating the exact error, possible cause, stack, etc.

• In the other hand think that friendly is risky...

So the answer is: Yes, it is a security problem. The information will help a potential attacker to know more about your API.

Common ways of doing it?

In ASP.NET you have setting in web.config to control how verbose are the errors (CustomErrors).

Default settings shows a generic safe error, except that you are browsing from the same computer, then it shows full error. This way developers in their local computers can see the errors but once deployed to an environment detailed error information cannot be seen.

<?xml version="1.0"?>
<configuration>
    <system.web>
        <customErrors mode="Off"/>
    </system.web>
</configuration>