Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (2.11)  

CWE-489: Leftover Debug Code

Weakness ID: 489
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The application can be deployed with active debugging code that can create unintended entry points.

Extended Description

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. 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.

+ Time of Introduction
  • Implementation
  • Build and Compilation
  • Operation
+ Applicable Platforms



+ Modes of Introduction

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, this oversight during the "software process" allows attackers access to debug functionality.

+ Common Consequences
Access Control

Technical Impact: Bypass protection mechanism; Read application data; Gain privileges / assume identity; Varies by context

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

Phases: Build and Compilation; Distribution

Remove debug code before deploying the application.

+ Other Notes

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
ChildOfCategoryCategory1002SFP Secondary Cluster: Unexpected Entry Points
Software Fault Pattern (SFP) Clusters (primary)888
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
Software Fault PatternsSFP28Unexpected access points
+ 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
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-06-23CWE Content TeamMITREInternal
updated Description, Modes_of_Introduction, Other_Notes, Time_of_Introduction
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings

More information is available — Please select a different filter.
Page Last Updated: May 05, 2017