<br />

**OWASP category:** [MASVS-CODE: Code Quality](https://mas.owasp.org/MASVS/10-MASVS-CODE)


## Overview

Releasing production builds that include Testing or Debug features can
negatively impact the security posture of the application. These functionalities
are used to help developers discover and identify bugs within intended
application use cases prior to, or after a new version release, and shouldn't
be publicly accessible.

Examples of Testing/ Debug features are:

- Hidden menus
- Options to enable debug logs
- Options to alter application flow
- Options to circumvent payment or subscription processes
- Options to circumvent authentication
- Tests for application-specific activities

All the preceding can be leveraged by a malicious user in order to alter the
application's intended flow or retrieve system information to tailor further
attacks.

The risk introduced by leaving exposed Testing or Debug features may vary
according to the action associated with the debug capabilities itself.

Another area of risk for the application is the attribute **android:debuggable**
set within the AndroidManifest.xml element **`<application>`** . As reported in
the [**android:debuggable**](https://developer.android.com/topic/security/risks/android-debuggable) article,
deploying a production application with the aforementioned value set, allows
malicious users to access administrative resources that are otherwise
inaccessible.

## Impact

A malicious user interacting with a Testing or Debug feature in a production
build can lead to unexpected results. The impact of any action is directly
connected with the permissions assigned to the feature. The higher the
permissions, the higher the impact that an active exploitation can have. Such
functionalities within an application can be used to circumvent a number of
protections, bypass paywalls, retrieve system or user related information, or
trigger testing activities.

## Mitigations

### Avoid using debug components

Test or debug functionalities should never be implemented within production
application components such as activities, broadcast receivers, services or
content providers since, if exported, can be run by any other process on the
device.
Setting the debug component as not exported
([**android:exported="false"**](https://developer.android.com/topic/security/risks/android-exported)) does
not constitute a valid protection for the capabilities since any rooted device
can still execute it through the Android Debug Bridge (ADB) tool if the debug
option is enabled.

### Limit debug or test features to staging builds

The execution of any test or debug function within applications should be
limited only to a restricted set of Staging builds to allow only developers to
debug or test application's features in a controlled environment.
This can be obtained by creating a dedicated test or debug build of the
application and advanced instrumented tests for it in order to ensure that any
test or debug feature is run on an isolated version.

### Implement automated UI tests

When running tests on an application, opt for automated UI tests since they are
repeatable, can be executed in a separated environment and are not prone to
human errors.

## Resources

- [Dev guidance on advanced testing setups](https://developer.android.com/studio/test/advanced-test-setup)
- [Dev guidance on automating UI tests](https://developer.android.com/training/testing/instrumented-tests/ui-tests)
- [android:debuggable](https://developer.android.com/topic/security/risks/android-debuggable)
- [android:exported](https://developer.android.com/topic/security/risks/android-exported)
- [Debuggable Apps in Android Market](https://labs.withsecure.com/publications/debuggable-apps-in-android-market)
- [Can debug code cause security vulnerabilities?](https://www.coderskitchen.com/an-debug-code-cause-security-vulnerabilities/)