Improper handling of errors can introduce a
variety of security problems for a web site. The most common problem
is when detailed internal error messages such as stack traces,
database dumps, and error codes are displayed to the user (hacker).
These messages reveal implementation details that should never be
revealed. Such details can provide hackers important clues on
potential flaws in the site and such messages are also disturbing to
Web applications frequently generate error
conditions during normal operation. Out of memory, null pointer
exceptions, system call failure, database unavailable, network
timeout, and hundreds of other common conditions can cause errors to
be generated. These errors must be handled according to a well
thought out scheme that will provide a meaningful error message to
the user, diagnostic information to the site maintainers, and no
useful information to an attacker. For example, if a hacker enters
an invalid command, the web server sends an error message back to the
end-user. This message should be generic, but often times presents
excessive information such as "User Name Correct, Password
Incorrect." That could help the attacker focus their illicit
activities on the password cracking activities.
Even when error messages don't provide a lot of
detail, inconsistencies in such messages can still reveal important
clues on how a site works, and what information is present under the
covers. For example, when a user tries to access a file that does not
exist, the error message typically indicates, "file not found".
When accessing a file that the user is not authorized for, it
indicates, "access denied". The user is not supposed to know the
file even exists, but such inconsistencies will readily reveal the
presence or absence of inaccessible files or the site's directory
One common security problem caused by improper
error handling is the fail-open security check. Assume no access
until proven otherwise. All security mechanisms should deny access
until specifically granted, not grant access until denied, which is a
common reason why fail open errors occur. Other errors can cause the
system to crash or consume significant resources, effectively denying
or reducing service to legitimate users.
Good error handling mechanisms should be able to
handle any feasible set of inputs, while enforcing proper security.
Simple error messages should be produced and logged so that their
cause, whether an error in the site or a hacking attempt, can be
reviewed. Error handling should not focus solely on input provided by
the user, but should also include any errors that can be generated by
internal components such as system calls, database queries, or any
other internal functions.
A7.2 Environments Affected
All web servers, application servers, and web
application environments are susceptible to error handling problems.
A7.3 Examples and References
A7.4 How to Determine If You Are Vulnerable
Typically, simple testing can determine how your
site responds to various kinds of input errors. More thorough testing
is usually required to cause internal errors to occur and see how the
Another valuable approach is to have a detailed
code review that searches the code for error handling logic. Error
handling should be consistent across the entire site and each piece
should be a part of a well-designed scheme. A code review will reveal
how the system is intended to handle various types of errors. If you
find that there is no organization to the error-handling scheme or
that there appear to be several different schemes, there is quite
likely a problem.
A7.5 How to Protect Yourself
A specific policy for how to handle errors should
be documented, including the types of errors to be handled and for
each, what information is going to be reported back to the user, and
what information is going to be logged. All developers need to
understand the policy and ensure that their code follows it.
In the implementation, ensure that the site is
built to gracefully handle all possible errors. When errors occur,
the site should respond with a specifically designed result that is
helpful to the user without revealing unnecessary internal details.
Certain classes of errors should be logged to help detect
implementation flaws in the site and/or hacking attempts.
Return a simple error message to the user and log a more detailed
error message to the server.
the user with diagnostic information (e.g., data validation errors),
but do NOT provide developer level diagnostic/debug information.
error messages regarding user ID and password errors; do NOT
describe the password complexity.
Data validation errors are okay.
Review access logs; look for anomalies
your site contains sensitive data, log access to the system and
review error logs periodically
Very few sites have any intrusion detection
capabilities in their web application, but it is certainly
conceivable that a web application could track repeated failed
attempts and generate alerts. Note that the vast majority of web
application attacks are never detected because so few sites have the
capability to detect them. Therefore, the prevalence of web
application security attacks is likely to be seriously
The OWASP Filters project is producing reusable
components in several languages to help prevent error codes leaking
into user's web pages by filtering pages when they are constructed
dynamically by the application.