== Why is this an issue?

Servlets are components in Java web development, responsible for processing HTTP requests and generating responses.
In this context, exceptions are used to handle and manage unexpected errors or exceptional conditions that may
occur during the execution of a servlet.

Catching exceptions within the servlet allows us to convert them into meaningful, user-friendly messages.
Otherwise, failing to catch exceptions will propagate them to the servlet container, where the default
error-handling mechanism may impact the overall security and stability of the server.

Possible security problems are:

1. *Vulnerability to denial-of-service attacks:*
   Not caught exceptions can leave the servlet container in an unstable state, which can exhaust the available resources
   and make the system unavailable in the worst cases.

2. *Exposure of sensitive information:*
   Exceptions handled by the servlet container, by default, expose detailed error messages or debugging information to
   the user, which may contain sensitive data such as stack traces, database connection, or system configuration.

Unfortunately, servlet method signatures do not force developers to handle `IOException` and `ServletException`:
[source,java]
----
public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
}
----

To prevent this risk, this rule enforces all exceptions to be caught within the "do*" methods of servlet classes.

== How to fix it

Surround all method calls that may throw an exception with a `try/catch` block.

=== Code examples

In the following example, the `getByName` method may throw an `UnknownHostException`.

==== Noncompliant code example

[source,java,diff-id=1,diff-type=noncompliant]
----
public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
  InetAddress addr = InetAddress.getByName(request.getRemoteAddr()); // Noncompliant
  //...
}
----

==== Compliant solution

[source,java,diff-id=1,diff-type=compliant]
----
public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
  try {
    InetAddress addr = InetAddress.getByName(request.getRemoteAddr());
    //...
  }
  catch (UnknownHostException ex) {  // Compliant
    //...
  }
}
----

== Resources

=== Articles & blog posts

* https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure[OWASP Top 10 2017 Category A3] - Sensitive Data Exposure
* https://cwe.mitre.org/data/definitions/600[MITRE, CWE-600] - Uncaught Exception in Servlet
* https://wiki.sei.cmu.edu/confluence/x/-zZGBQ[CERT, ERR01-J.] - Do not allow exceptions to expose sensitive information

ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Handle the following exception(s) that could be thrown by "xxx": ExceptionType.


'''
== Comments And Links
(visible only on this page)

=== on 19 Sep 2014, 13:35:26 Freddy Mallet wrote:
@Ann:

* I would activate this rule by default because I don't see when this rule might generate some false-positives
* I would associate the rule to the SQALE sub-characteristic "Error"
* I guess this rule belongs to OWASP Top 10 ?

=== on 22 Sep 2014, 11:44:56 Ann Campbell wrote:
For the record: not in the OWASP Top 10

=== on 12 Dec 2014, 21:26:02 Sébastien Gioria wrote:
as the result could be to stackTrace or information reply on the browser, we could consider this issue in OWASP-TOP10-A6

=== on 15 Dec 2014, 10:22:03 Freddy Mallet wrote:
This is a good point [~sebastien.gioria] which raises another question: for the time being we tag a rule relating to a CWE item with tag "owasp-top10" if and only if in the MITRE CWE referential, this CWE item is part of http://cwe.mitre.org/data/definitions/928.html[CWE-928: Weaknesses in OWASP Top Ten (2013)]. Do you think this is a too strong requirement [~sebastien.gioria] ?

=== on 20 Jul 2015, 07:49:37 Ann Campbell wrote:
Tagged java-top by Ann

=== on 13 Nov 2019, 15:06:56 Guillaume Dequenne wrote:
Updating the message to explicitly mention which unhandled exception type triggered the issue (as the method invocation could already be in a try/catch block without a correct catch clause).

endif::env-github,rspecator-view[]
