Whenever an unhandled exception makes it into production somehow - whatever the reason - there's generally an option (especially with .NET programs) to print out a stack trace to the end user before the program ends completely. Even though this helps with debugging the program, if the user sends a copy of the stack trace in a bug report, it is definitely a security concern. You don't want them being able to see your code like that - not without them going through a lot of extra hassle.

But what if the text of the stack trace were encrypted before being printed to the screen? Would this be something which is safe, viable, etc.? Or would it still be something particularly worth avoiding?


I'm aware of decompilation and the issues that produces. There are obfuscators though, and even though they're pretty much anything but perfect, they are better than no protection at all. It has been said that locks are for honest people, but everybody still uses them.

  • 2
    If the user can encrypt it (even if with a public key, so that he can't decrypt it), he can also access the data before he encrypts it. Encrypting it can reduce your security exposure, e.g. when the user emails it to you. But it can't stop a malicious end user from examining the app he's running.
    – Tim S.
    May 1, 2014 at 16:47
  • 1
    You say "You don't want them being able to see your code like that" and that it is "definitely a security concern". Your concern sounds more like one of potential embarrassment. Certainly the contents of the trace are irrelevant for the user and so they could be encoded, and they should not need to see the actual contents. You've probably seen crash reports from Firefox or Thunderbird. Their approach of a simple dialog to send a crash report works well. You might choose to give the user the option to see what the report contains for reassurance purposes.
    – Nick
    May 1, 2014 at 17:54
  • 7
    A reverse engineer could use tools to get a stack trace at any point in time. Decide whether a stack trace is useful to you, and if so there's probably more upside to you and your end users for you to have it than not. Often traces may not be, but we had one a couple of days ago and it proved very useful as we could reason and home in on where an issue occurred despite no symbolic information being present for the stack frames in our component (a shared library) and function calls being shown just as ??
    – Nick
    May 1, 2014 at 18:03
  • 3
    Your attitude towards security is completely backwards. You talk about the safety of the code that just crashed which is like saying that we want to make sure that the customer doesn't harm their toaster when it bursts into flames. The customer who is running your code is the entity that has to be protected from harm, not your code! The customer who is running your code already has full knowledge of the code; there are no secrets. May 2, 2014 at 14:18
  • 1
    YouTube does this: news.ycombinator.com/item?id=18234750
    – caw
    Nov 11, 2018 at 0:22

5 Answers 5


Think about why you want to do this. It is in my opinion, entirely pointless.

If the exception occurred on the server side, handle and log it there. There is absolutely no point in displaying the stack trace to the user.

If the exception occurred on the client side, in a thick client style web app, desktop app, mobile app etc, there is absolutely no point in encrypting it. Any determined enough user can decompile or reverse engineer client side code. In fact, how would you encrypt the data? Encryption implies an encryption key, and this key has to be stored somewhere.

I also question what a normal user can do when you display the stack trace. If crash data is important information, implement some sort of reporting functionality for diagnostics.

  • What do you mean by "thick"? Also, part of the thinking was that if the program crashed dead in the water somehow, then maybe the end user could submit the encrypted stack trace in a bug report. May 1, 2014 at 12:43
  • @Panzercrisis Think javascript-heavy web apps where application logic lives on the client instead of the server.
    – user10211
    May 1, 2014 at 12:47
  • 7
    For encryption he could use a public key like with PGP, which can be stored in the code without problem. The private key is held by himself and kept private.
    – SPRBRN
    May 1, 2014 at 12:51
  • 1
    @SPRBRN But the application actually putting the data on the stack that gets dumped is under user control, so it is still redundant.
    – deed02392
    May 1, 2014 at 14:24
  • 1
    I'm replying to the comment on "how" to encrypt the data, and that encryption implies storing a key. In this answer that is posed as a problem, which it is not using a public key.
    – SPRBRN
    May 1, 2014 at 14:56

A stack trace rarely includes any information which is of a security concern. Sure, it might show names of source files, line numbers and function names, but I could hardly imagine any situation where these would be valuable info. Especially considering that this information is stored in the executable of the program which runs on the users machine. The user could extract that information from the application manually when they would want to.

One might argue from a User Experience point of view whether or not this information is useful for the user. It might help them to self-diagnose problems. They could enter the stack trace into a search engine and might find someone who had the same problem and solved it somehow. An especially tech-savvy user might even use the information to diagnose the problem themselves (when the stack-trace is in a function from a graphics API, the problem might be my graphic card driver, for example). A less tech-savvy user, however, could be confused by an overly verbose error message. But as I said that's all a UX concern and not security-related.


I guess this is not a web application (for which you could log the stack trace on the server) but something like a desktop app?

Take the following case: I run the program locally, and it crashes. I get a message that I can report the problem to the developer. I want to see what is sent. Then I see some encrypted information. I wonder what it is, and I wonder if the programs sends some private information to the developer. So what about privacy? How do you guarantee that you don't send personal info?

  • Indeed - that's the reason why people are so weary of Windows "report problem to Microsoft" feature. You aren't told what information they receive so you are afraid it might violate your privacy.
    – Philipp
    May 3, 2014 at 9:43

If you are dealing with a .Net application, there isn't much reason to encrypt it unless you are using a pretty good obfuscator. .Net can be trivially decompiled and encrypting the stack dump after the keys to the kingdom are already out in to open is not all that helpful.

If they are running it locally, then they have the ability to alter and analyze the code directly, including attaching a debugger and simply catching the stack themselves. If it is running on a server, then you can log it rather than displaying it to the user.

An average user isn't going to be able to make any use of a call stack and any user that can is already going to know about tools like Reflector and how to use debuggers to catch the information.

In the event that you actually are using obfuscation, then yes, encrypting the stack trace could be useful for making it more likely that both that data is unaltered when submitted to you and also protecting information about the call stack from would be attackers that would use it to try to figure out the obfuscation, though properly obfuscated, most of the call stack is going to be scrambled to begin with anyway since replacing meaningful names with useless ones is one of the first things an obfuscator does.

The main reason I could see to encrypt your crash reports is to reduce the likelihood of someone tampering with the crash report and also to protect any user data that is contained within the report. I don't really see a situation where the information the user could glean about the call stack is a major concern, at least not for a .Net application.

  • 1
    "encrypting the stack trace could be useful for ensuring both that data is unaltered when submitted to you" - this is not correct, invalid data could still be sent since the user can encrypt with the key if they find it in the binary (potentially quite easy if you analyse for candidates based on entropy and typical key sizes).
    – deed02392
    May 1, 2014 at 14:29
  • @deed02392 - yes, that is true, I altered the wording to reflect closer to my original intent, which was to convey it is less likely to have been tampered with, though it is not guaranteed if it is a determined attacker with sufficient knowledge to extract the key, though proper obfuscation should make that slightly more challenging (though by no means impossible). May 1, 2014 at 14:40
  • Yup, since we're talking about crypto, just wanted it to be clear it doesn't authenticate the message like a signature could in a very similar context (not possible because the private key won't be available).
    – deed02392
    May 1, 2014 at 15:22

The other users already questioned the need for showing the stack trace to the user.

I think there are two reasons why you thought about that: First, you are the user and want to inspect errors you already know about. Or you want the user give the ability to send in the encrypted report.

There is a much better way to deal with this: Let the application automatically report errors to a hosted error tracking system like Exceptiontrap (Disclaimer: I'm the founder).

This provides you with several advantages:

  • You will be informed in real time about all errors
  • You know how often a specific error happend and when
  • The system groups the errors to error groups
  • You'll have the stack trace and extra information about the server environment, request parameters and so on
  • Additionally it removes the security concern you were afraid of

As I said before, I'm the founder of Exceptiontrap, but there are several other services available.

You must log in to answer this question.

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