21

It is a known fact that exposing the exception information to the end user provides security risks since an adversary can user that to figure out how things work internally and attack it. But what about a web service, where that information might be relevant to the developers that consume the API?

On one hand exposing full stacktrace and even the message is risky since it might contain some database information e.g. on the other hand if something goes wrong and the server just says 500 "sorry", then developers would be frustrated. I guess really the proper way is to handle all exceptions you know of in a secure manner, i.e. catch business/validation exceptions and return it back with special error codes and messages (no stacktrace) and for all unknown still make 500 "sorry".

But I would like to here what are the common ways of doing it and which approach should be taken from security point of view.

Improve this question
7
  • Relevant: owasp.org/index.php/Information_Leakage
    – d0nut
    Apr 25, 2016 at 14:02
  • 9
    My approach designing an interface is usually the same as the law's: Anything you say can, and will, be used against you. Don't share anything you don't need to.
    – 1ace
    Apr 25, 2016 at 15:32
  • Google Dorks - Google cached stack trace/error dump pages containing anything from obtuse jargon to explicit access credentials. I've come across several that give away the keys to the kingdom. Writing this to a local file would have saved the embarrassment from that one error catch routine that someone forgot to sanitize.
    – Fiasco Labs
    Apr 25, 2016 at 17:43
  • @1ace that is extremely clever. I will definitely use that whenever someone tries to argue with me that it's okay to leave stacktraces accessible to users.
    – d0nut
    Apr 25, 2016 at 19:22
  • I would not call this question a duplicate. The difference is between end users and developers.
    – Stig Hemmer
    Apr 26, 2016 at 9:44

3 Answers 3

Reset to default
27

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.

Improve this answer
2
  • 6
    And you can still dump the stack trace to a log file (if you can catch the exception) together with some user info in case you want to know more when the user reports "Yesterday around two o'clock I was doing ...., and suddenly..."
    – user13695
    Apr 25, 2016 at 14:59
  • Where possible I try to give the users a short code that identifies the exception with the text "when contacting support or your systems administrator, please quote this to help us look into the issue more quickly". Good users will do just that and you then don't have to deal with approximate times and other guesswork or Chinese whispers between you and them. "Bad users" will forget to note it - they get their problems dealt with more slowly than good users - and of course a really bad exception may block the log and code generation, but often it can be very useful.
    – David Spillett
    Apr 25, 2016 at 19:57
7

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.

Youtube invalid video code

  • 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:

Youtube internal error

Improve this answer
7
  • 10
    Or put it in a QR code so that you can still recover the data when they inevitably send you a screenshot instead of pasting the text.
    – Random832
    Apr 25, 2016 at 16:44
  • 6
    It's probably better to log the stacktrace on the server and associate it with an special ID and send the user just the ID as in "If you want us to look into this please contact us and report us the following ID: xxxxxxx".
    – Bakuriu
    Apr 25, 2016 at 19:41
  • 1
    @Bakuriu, you are probably right, but it is a whole new question why youtube did it this way. I think it is not always possible to log critical error in a reliable way, but spitting it to the user is as easy as "print(encrypt(stacktrace))".
    – deniss
    Apr 25, 2016 at 19:51
  • A common terminology for this distinction are client vs. server errors (cf. the SOAP specification)
    – meriton
    Apr 26, 2016 at 0:38
  • Actually, there are three kind of exceptions.
    – Pharap
    Apr 26, 2016 at 4:17
5

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>
Improve this answer
2
  • 2
    Stack trace is just as useless for API consumer as it is for UI user. He does not have access to source code.
    – Oleg V. Volkov
    Apr 25, 2016 at 22:47
  • 1
    Agree. It is only useful for API developer. However many times API developer and API consumer is the same team/person...
    – Oscar Foley
    Apr 29, 2016 at 8:37

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