Android has a built-in backup mechanism that can save and restore application data.

Why is this an issue?

When application backup is enabled, local data can be exported to Google Cloud or to an external device via adb backup. This rule flags the android:allowBackup attribute set to true in the Android manifest without a backup restriction such as android:fullBackupContent (API level 23-30) or android:dataExtractionRules (API level 31+). By default, backup is enabled and includes shared preferences files and files under paths returned by getDatabasePath(String), getFilesDir(), getDir(String, int), and getExternalFilesDir(String).

What is the potential impact?

When application backup is enabled without restriction, sensitive data stored in local files, databases, or shared preferences may be exposed to unauthorized parties through backup storage. Restoring from an untrusted backup source can also corrupt application state or inject malicious data.

How to fix it

Code examples

Noncompliant code example

<application
    android:allowBackup="true"> <!-- Noncompliant -->
</application>

Compliant solution

Disable application backup.

<application
    android:allowBackup="false">
</application>

When targeting Android 12 (API level 31) or above, use android:dataExtractionRules to define which files are included or excluded from backups. For apps targeting Android 6.0 to 11 (API level 23 to 30), use android:fullBackupContent instead.

Noncompliant code example

<!-- Targeting API 31+ (Android 12 or higher) -->
<application
    android:allowBackup="true"> <!-- Noncompliant -->
</application>

Compliant solution

<application
    android:allowBackup="true"
    android:dataExtractionRules="@xml/extraction_rules">
</application>

Other approaches to control which data is backed up include:

Going the extra mile

Even when backup scope is properly restricted, additional hardening measures are recommended:

Resources

Documentation

Standards