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

• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• Mobile AppSec Verification Standard - Code Quality and Build Setting Requirements
• OWASP Mobile Top 10 2016 Category M10 - Extraneous Functionality
• MITRE, CWE-215 - Information Exposure Through Debug Information
• developer.android.com - Prepare for release
• learn.microsoft.com - ASP.NET Error Handling