Development tools and frameworks usually have options to make debugging easier for developers. Although these features are useful during
development, they should never be enabled for applications deployed in production.
Activating a development feature in production can have an important range of consequences depending on its use:
- Technical information leak; generally by disclosing verbose logging information to the application’s user.
- Arbitrary code execution; generally with a parameter that will allow the remote debugging or profiling of the application.
In all cases, the attack surface of an affected application is increased. In some cases, such features can also make the exploitation of other
unrelated vulnerabilities easier.
Ask Yourself Whether
- The development of the app is completed and the development feature is activated.
- The app is distributed to end users with the development feature activated
There is a risk if you answered yes to any of those questions.
Recommended Secure Coding Practices
Applications should be released without any development feature activated. When such features are required when in the development process of the
application, they should only apply to a build variant that is dedicated to development environments. That variant should not be set as the default
build configuration to prevent any unattended development feature exposition.
Sensitive Code Example
In AndroidManifest.xml
the android debuggable property is set to true
. The application will therefore be debuggable.
<application
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
android:debuggable="true"
android:theme="@style/AppTheme">
</application> <!-- Sensitive -->
In a web.config
file, the customErrors
element’s mode
attribute is set to Off
. The application
will disclose unnecessarily verbose information to its users upon error.
<configuration>
<system.web>
<customErrors mode="Off" /> <!-- Sensitive -->
</system.web>
</configuration>
Compliant Solution
In AndroidManifest.xml
the android debuggable property is set to false
:
<application
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
android:debuggable="false"
android:theme="@style/AppTheme">
</application> <!-- Compliant -->
In a web.config
file, the customErrors
element’s mode
attribute is set to On
:
<configuration>
<system.web>
<customErrors mode="On" /> <!-- Compliant -->
</system.web>
</configuration>
See