Leftover Debug Code
Weakness ID: 489 (Weakness Base)Status: Draft
+ Description

Description Summary

The application can be deployed with active debugging code that can create unintended entry points.
+ Time of Introduction
  • Implementation
  • Operation
+ Applicable Platforms



+ Common Consequences

The severity of the exposed debug application will depend on the particular instance. At the least, it will give an attacker sensitive information about the settings and mechanics of web applications on the server. At worst, as is often the case, the debug application will allow an attacker complete control over the web application and server, as well as confidential information that either of these access.

+ Demonstrative Examples

Example 1

Debug code can be used to bypass authentication. For example, suppose an application has a login script that receives a username and a password. Assume also that a third, optional, parameter, called "debug", is interpreted by the script as requesting a switch to debug mode, and that when this parameter is given the username and password are not checked. In such a case, it is very simple to bypass the authentication process if the special behavior of the application regarding the debug parameter is known. In a case where the form is:

(Bad Code)
Example Language: HTML 
<FORM ACTION="/authenticate_login.cgi">
<INPUT TYPE=TEXT name=username>
<INPUT TYPE=PASSWORD name=password>

Then a conforming link will look like:


An attacker can change this to:


Which will grant the attacker access to the site, bypassing the authentication process.

+ Potential Mitigations

Remove debug code before deploying the application.

+ Other Notes

A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the application. In web-based applications, debug code is used to test and modify web application properties, configuration information, and functions. If a debug application is left on a production server, an attacker may be able to use it to perform these tasks. When this sort of debug code is left in the application, the application is open to unintended modes of interaction. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the application.

While it is possible to leave debug code in an application in any language, in J2EE a main method may be a good indicator that debug code has been left in the application, although there may not be any direct security impact.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class485Insufficient Encapsulation
Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
Research Concepts (primary)1000
ChildOfCategoryCategory731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
Weaknesses in OWASP Top Ten (2004) (primary)711
MemberOfViewView630Weaknesses Examined by SAMATE
Weaknesses Examined by SAMATE (primary)630
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsLeftover Debug Code
OWASP Top Ten 2004A10CWE More SpecificInsecure Configuration Management
+ White Box Definitions

A weakness where code path has a statement that defines an entry point into an application which exposes additional state and control information

+ Content History
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential Mitigations, Time of Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
2008-09-08CWE Content TeamMITREInternal
updated Common Consequences, Relationships, Other Notes, Taxonomy Mappings
2009-07-27CWE Content TeamMITREInternal
updated Demonstrative Examples
2009-10-29CWE Content TeamMITREInternal
updated Common Consequences