Tag Archives: Improper Error Handling

Information Leakage and Improper Error Handling

Photo: Andres Rueda

Photo: Andres Ruedahis

This is the sixth-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What is Information Leakage and Improper Error Handling

Information leakage and improper error handling happen when web applications do not limit the amount of information they return to their users. A classic example of improper error handling is when an application doesn’t sanitize SQL error messages that are returned to the user. Upon receiving a SQL error message an attacker will immediately identify a place for identifying injection flaws.

Although preventing error messages from reaching users will not prevent vulnerabilities from occurring, it does make it difficult for an attacker to accomplish his goal and it is also an industry best practice.

An Example of Information Leakage

Common examples of information leakage include helpful error messages and service banners. Developers and system administrators often forget or disregard how something as simple as a server banner can be used by an attacker.

As an example, if your server is running Apache and you return the server header with your responses, an attacker could leverage this to fingerprint the version of the web server you are running.

Using nmap an attacker could send a few packets at your application server using the command, nmap -sV -p 80 192.168.1.100 and identify the following:

Interesting ports on 192.168.38.132:
PORT    STATE SERVICE  VERSION
80/tcp  open  http     Apache httpd 1.3.37

The attacker has now identified your Apache version and can now search for vulnerabilities affecting that version of Apache.

An Example of Improper Error Handling

Attackers attempt to leverage information that applications freely volunteer. If an application displays an error messages to the user (attacker), there is not guarantee that the user will “ignore” this error message.

Developers typically forget to properly handle their error messages. Stack traces and SQL errors are two examples of very commonly forgotten errors that should be handled.

Attackers love seeing error messages such as:

ERROR:  unterminated quoted string at or near "'''"

How Do You Prevent Information Leakage and Improper Error Handling

When developing applications, developers should assume all of the users are hostile. As a developer having this mentality will greatly aid you in developing secure applications.

All information returned from a web server should be reviewed for potential leakage. This can be automated by a QA team using a fuzzer.

Developers should also use a standard exception handling architecture to prevent information leakage from occurring. This architecture should be used and shared across the entire development team. All developers should handle their errors the same way.

Developers or product managers may also decide to create a default error handler which returns sanitized error messages for most users in production for all error paths. Doing this will greatly reduce the attack surface that can be exploited through error message generation.

OWASP Top 10


When developing a security strategy for web applications many companies have no idea where to begin. The Open Web Application Security Project (OWASP) understood this problem and developed the OWASP Top 10.

The OWASP top 10 are the top 10 vulnerabilities that are found in web applications. This will begin a 10-part series dedicated to each of these vulnerabilities.

If you are a developer, you should understand these vulnerabilities. Understanding them is critical into introducing less vulnerabilities into your code.

The OWASP Top 10:
A1 – Cross Site Scripting (XSS)
A2 – Injection Flaws
A3 – Malicious File Execution
A4 – Insecure Direct Object Reference
A5 – Cross Site Request Forgery (CSRF)
A6 – Information Leakage and Improper Error Handling
A7 – Broken Authentication and Session Management
A8 – Insecure Cryptographic Storage
A9 – Insecure Communications
A10 – Failure to Restrict URL Access