The release build of an application is generally meant for distribution to end users. By making this target debuggable, you expose your application to unnecessary risks. Debug instructions or error messages can leak detailed information about the system, like the application’s path or file names.

== Why is this an issue?

When you build a release version of your application, you're creating a distributable package of your code. Making release builds debuggable will make it much easier for someone to reverse-engineer your application. This means they can potentially understand your code's logic, extract sensitive information like API keys, or even modify your application for malicious purposes.

Release builds are meant for distribution to end users and is therefore under constant scrutiny. Making these builds debuggable creates a serious vulnerability. While debugging builds can be used for troubleshooting, failing to enable it for release builds exposes your application to unnecessary risks.

== How to fix it in Android

=== Code examples

==== Noncompliant code example

[source,kotlin,diff-id=1,diff-type=noncompliant]
----
android {
    buildTypes {
        release {
            isDebuggable = true // Sensitive
        }
    }
}
----

==== Compliant solution

[source,kotlin,diff-id=1,diff-type=compliant]
----
android {
    buildTypes {
        release {
            isDebuggable = false
        }
    }
}
----

== Resources
=== Documentation

* https://developer.android.com/studio/publish/preparing[developer.android.com] - Prepare for release
* https://developer.android.com/privacy-and-security/risks/android-debuggable[developer.android.com] - android:debuggable

=== Standards

* OWASP - https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[Top 10 2021 Category A5 - Security Misconfiguration]
* OWASP - https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure[Top 10 2017 Category A3 - Sensitive Data Exposure]
* OWASP - https://owasp.org/www-project-mobile-top-10/2016-risks/m9-reverse-engineering[Mobile Top 10 2016 Category M9 - Reverse Engineering]
* OWASP - https://owasp.org/www-project-mobile-top-10/2016-risks/m10-extraneous-functionality[Mobile Top 10 2016 Category M10 - Extraneous Functionality]
* OWASP - https://owasp.org/www-project-mobile-top-10/2023-risks/m7-insufficient-binary-protection[Mobile Top 10 2024 Category M7 - Insufficient Binary Protection]
* OWASP - https://owasp.org/www-project-mobile-top-10/2023-risks/m8-security-misconfiguration[Mobile Top 10 2024 Category M8 - Security Misconfiguration]
* OWASP - https://mas.owasp.org/checklists/MASVS-CODE/[Mobile AppSec Verification Standard - Code Quality and Build Setting Requirements]
* CWE - https://cwe.mitre.org/data/definitions/489[CWE-489 - Active Debug Code]
* CWE - https://cwe.mitre.org/data/definitions/215[CWE-215 - Information Exposure Through Debug Information]
