Web Application Security

Error Handling in Java web.xml

What is it and why should I care?

Error or exception handling is an important, but often ignored, part of any application. And although there’s a lot to be said on the topic I’m going to cover only a few of the most critical cases in J2EE Web applications.

Essentially, one of the biggest worries about exception handling is that you don’t actually handle the exception. Instead, your code − or the code of some 3rd party library you’re using − allows an exception to bubble up. Once the exception reaches the boundary of your application and enters the container, the specific container/application server you are using determines what semantics are applied in handling the exception. Often times, by default, a standard error page is applied and the exception stack trace is printed on the screen in all its glory. This is definitely a problem, because it gives attackers a lot of information about the system, and can lead to further attacks.

What should I do about it?

Handling this issue is fairly straightforward. The basic advice is to provide error handlers for at least java.lang.Throwable (catches any Java exceptions or errors), and provide more specific handlers for individual exceptions and http error codes (the most common being 404 and 500).

An example snippet that can be applied to the web.xml is below:













Note: error.jsp page should be generic and provide a canned response message of a type that contains no detail that could help an attacker fingerprint the app in any way.

There’s a lot more to know and do in regard to handling exceptions in your application. However, from a security perspective, catching Throwables and the specified error codes provides much of the protection you need.





  • Matt Seil

    Catching Throwables in Java is a known antipattern. A common problem that occurs is described here: http://www.javatuning.com/why-catch-throwable-is-evil-real-life-story/

    Also, if you’re in the camp that believes “checked exceptions lead to bad code” catching throwable also breaks the distinction between checked and unchecked exceptions because you’re stating “catch everything!”

  • Trust me, im teacher

    Yeah, but this isn´t that case. In this code, there is no “throwable catching”, just declaring a GENERIC page which will handle all types of exceptions.

  • Pingback: xml - Java EE - more generic error code mapping - CSS PHP()