Our web application has an error page that displays the absolute URL path and query of the page on which the error occurred, the date/time of the error, and the exception message. (We do not display the stack trace. That is an obvious vulnerability.)

Is it a vulnerability to display exception messages in an error page?

For maximum security, what should we display in an error page? What should we not display?

EDIT: My hunch is that it is a vulnerability, but I want to hear an expert opinion.

  • 5
    I'd think of it the other way 'round: what potential benefit would showing the error message to the user have? Jun 9, 2011 at 17:19
  • @Simon I think none. Jun 9, 2011 at 18:19
  • Depending on the concrete situation it may be a good idea to have two modes of the application: A development mode which shows all the details and a production mode which display "Ooops, we are sorry an error occurred. Our support team has been notified of this error and will take appropriate actions to fix it." page. Don't confuse users with error messages they cannot do anything about. Jun 10, 2011 at 13:20
  • 1
    @Hendrik I prefer using an internal log file, or email if the app is high priority, while displaying a generic error. At best, give them an ID they can correlate to your log. That way, developers get a lot to work on, but attackers get nothing.
    – user2796
    Jun 10, 2011 at 18:04
  • 1
    @Soumya92 Thanks. > "At best, give them an ID they can correlate to your log." -- we are changing our page to do that. It will provide a generic error message, an apology for the inconvenience, the current date, and a number for us to be able to correlate their report to the log entry. Jun 10, 2011 at 18:13

3 Answers 3


In some cases, error messages induce vulnerabilities. In the area of cryptography, the padding oracle attack can recover a secret key by sending altered encrypted messages, and using an "oracle" which distinguishes between two kinds of failure ("padding was wrong" vs "there was a valid padding, but the resulting data was gibberish"). Detailed error messages have a strong potential for being such an oracle. In a more general, conceptual view, attackers will try to uncover weaknesses by prodding at the system and observing what happens, and more data can only help them. The exception message is not qualitatively distinct from the stack trace, in that respect; so if the stack trace is an "obvious" vulnerability, so must be the exception message too.


Path disclosure / path leakage can also be used to fingerprint apps and their underlying servers, in addition to providing enumeration of attack surface. Nearly every web application that utilizes dynamic pages will leak local web server paths, sometimes which contain usernames and obviously vulnerable directories.

They can also be leveraged during file inclusion or script inclusion attacks. Special care must be made for PHP/CTP, ASP/ASPX, and JSP/JSPX files in order to prevent path disclosure messages from being easily turned into a file inclusion attack, which can (for example) read local files.

  • 1
    Can also turn into XSS attacks...
    – AviD
    Jun 9, 2011 at 23:32

I wouldn't necessarily call it a vulnerability in itself. The exception alone probably isn't enough to breach the security of your server.

But it is a weakness that might reveal information that helps attackers, or gives them a foot in the door. For instance, it might reveal information about the code or software version. It might make it easier for attackers to try attacks and learn about how to tweak them to make them work.

Also, sometimes attackers are able to put together several weaknesses and combine them to build a full exploit. No one weakness on its own is a vulnerability, i.e., no one weakness on its own would allow attackers to breach the security of your system. But when attackers combine them in a clever way, sometimes they provide enough stepping stones to allow a full-fledged security breach.

For these reasons, I'd be inclined to be cautious about these kinds of "weaknesses". It seems safer to try to avoid them, if you can.

You must log in to answer this question.

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