备份的安全建议
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
OWASP 类别:MASVS-CODE:代码质量
概览
应用备份旨在保留用户的数据,以便日后恢复到新设备或在数据丢失时使用。现有的有关应用备份的安全建议因 Android 版本和设备制造商而异。这些建议的共同主题是,旨在确保不会泄露任何敏感数据。
标准 Android 备份系统提供了最安全、最可靠且最简单的解决方案,可让应用通过自动备份 (默认启用,无需任何工作即可实现,并且还可以扩展)和键值对备份将数据备份到云端或传输到新设备。我们推荐使用此解决方案,因为它将生成的备份数据存储在其他第三方应用无法访问的目录中,并促进静态加密、传输加密以及允许从备份中排除敏感数据的配置。
相反,如果应用实现的备份解决方案不依赖于标准 Android 备份系统,则可能会增加错误导致敏感数据泄露的可能性。导致用户数据泄露的非标准备份解决方案示例包括:提供“导出”或“备份”功能的应用,该功能会在其他应用可读取的目录中创建应用数据的副本,因此容易发生数据泄露(直接或通过其他漏洞)。
影响
在设置应用备份时遵循安全建议,可防止备份中可能包含的敏感数据发生潜在泄露。根据实际数据和攻击者的意图,敏感数据泄露可能会导致信息泄露、用户冒充和经济损失。
缓解措施
使用标准 Android 备份系统
标准 Android 备份系统始终会对传输中的数据和静态数据进行加密。无论您使用的是哪个 Android 版本,无论您的设备是否有锁屏,系统都会应用此加密。从 Android 9 开始,如果设备设置了锁定屏幕,则备份数据不仅会被加密,而且会使用 Google 不知道的密钥进行加密(锁定屏幕密钥会保护加密密钥,从而实现端到端加密)。
一般来说,请务必遵循数据存储和安全准则。
如果您的备份包含特别敏感的数据,我们建议您排除此类数据;如果无法排除,则要求使用端到端加密(如以下部分所述)。
从备份中排除数据
您可以使用规则文件(通常称为 backup_rules.xml
并放置在 res/xml
应用文件夹中)指定要从备份中排除哪些数据。备份规则的配置方式因所使用的 Android 版本而异:
- 对于 Android 12(API 级别 31)及更高版本,请向
AndroidManifest.xml
中的 <application>
元素添加 android:dataExtractionRules
属性:
- xml
xml
<application android:name="com.example.foo" android:dataExtractionRules="@xml/backup_rules_extraction">
…
</application>
然后,根据应用的数据持久性和安全性要求,按照更新后的配置格式配置 backup_rules.xml
文件。
backup_rules.xml
文件配置所需的格式允许开发者为云端和设备到设备 (D2D) 传输定义自定义备份规则。如果未设置 <device-transfer>
属性,系统会在点对点迁移期间传输所有应用数据。请务必注意,即使目标应用以 Android 12 或更高版本为目标平台,也应始终为搭载 Android 11(API 级别 30)或更低版本的设备指定包含一组额外备份规则的单独文件。
- 对于 Android 11 及更低版本,请将
android:fullBackupContent
属性添加到 AndroidManifest.xml
中的 <application>
元素:
- xml
xml
<application android:name="com.example.foo" android:fullBackupContent="@xml/backup_rules_full">
…
</application>
然后,根据应用的数据持久性和安全要求,使用备份用户数据一文中报告的语法配置 backup_rules.xml
文件。
要求使用端到端加密
如果您无法从备份中排除敏感数据,我们建议您要求进行端到端加密,这意味着仅允许在 Android 9 或更高版本上进行备份,并且仅在设置了锁屏的情况下进行备份。您可以使用 requireFlags="clientSideEncryption"
标志来实现此目的,该标志需要从 Android 12 开始重命名为 disableIfNoEncryptionCapabilities
并设置为 true
。
如果您无法使用标准 Android 备份系统
如果您无法使用 Standard Android Backup 系统,则需要安全地存储备份数据,同时指定要从备份中排除的数据更为复杂。这需要在代码级别指定,因此容易出错,存在数据泄露风险。在这种情况下,我们还建议您定期测试实现,以确保预期的备份行为没有发生任何变化。
资源
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-26。
[null,null,["最后更新时间 (UTC):2025-07-26。"],[],[],null,["# Security recommendations for backups\n\n\u003cbr /\u003e\n\n**OWASP category:** [MASVS-CODE: Code Quality](https://mas.owasp.org/MASVS/10-MASVS-CODE)\n\nOverview\n--------\n\nApp backups aim to preserve users' data so that it can later be restored to a\nnew device or in case of data loss. Existing security recommendations regarding\napp backups are nuanced, varying between Android versions and device\nmanufacturers. The common theme is that these recommendations aim at ensuring\nthat no sensitive data is leaked.\n\nThe Standard Android Backup system provides the most secure, robust, and easiest\nsolution for apps to back up their data to the cloud or to transfer data to a\nnew device through [Auto Backup](/identity/data/autobackup)(which is [enabled by default](/identity/data/backup), requires\nno work to implement and can also be extended) and [key-value backup](/guide/topics/data/keyvaluebackup). We\nrecommend using this solution because it stores the resulting backup data in\ndirectories that cannot be accessed by other 3p apps, as well as facilitating\nencryption at rest, encryption in transit, and configurations allowing for the\nexclusion of sensitive data from backups.\n\nIf instead an app implements a backup solution that is not reliant on the\nStandard Android Backup system, this could increase the likelihood of mistakes\nleading to leaks of sensitive data. Examples of non-standard backup solutions\nexposing user data to leaks include apps offering an \"export\" or \"backup\"\ncapability that creates a copy of the app data in directories readable by other\napps, and which is hence prone to being leaked (either directly or through other\nvulnerabilities).\n\nImpact\n------\n\nFollowing security recommendations when setting up app backups prevents the\npotential leak of sensitive data that backups might include. Depending on the\nactual data and on the attacker's intentions, sensitive data leak may lead to\ninformation disclosure, user impersonation, and financial loss.\n\nMitigations\n-----------\n\n### Use the Standard Android Backup system\n\nThe Standard Android Backup system always encrypts backup data in transit and at\nrest. This encryption is applied regardless of the Android version in use and of\nwhether your device has a lock screen. Starting from Android 9, if the device\nhas a lock screen set, then the backup data is not only encrypted, but encrypted\nwith a key not known to Google (the lock screen secret protects the encryption\nkey, thus enabling end-to-end encryption).\n\nIn general remember to follow the [data storage](/training/data-storage) and [security\nguidelines](/privacy-and-security/risks/sensitive-data-external-storage).\n\nIf your backup includes particularly sensitive data, then we recommend to either\nexclude this data or, if you cannot exclude it, require end-to-end encryption as\ndescribed in the following section.\n\n#### Excluding data from backup\n\nYou can specify which data to exclude from a backup using a rules file,\nconventionally called `backup_rules.xml`and placed in the `res/xml` app folder.\nThere are some differences in how backup rules are configured depending on the\nversion of Android that's used:\n\n- [For Android versions 12 (API level 31) and higher](/guide/topics/data/autobackup#include-exclude-android-12), add an `android:dataExtractionRules` attribute to the `\u003capplication\u003e` element within the `AndroidManifest.xml`:\n- xml `xml\n \u003capplication android:name=\"com.example.foo\" android:dataExtractionRules=\"@xml/backup_rules_extraction\"\u003e\n ...\n \u003c/application\u003e`\n\nThen, [configure](/guide/topics/data/autobackup#include-exclude-android-12) the `backup_rules.xml` file according to the\ndata persistence and security requirements of the application, following the\n[updated configuration format](/guide/topics/data/autobackup#xml-syntax-android-12).\n\nThe format required for the `backup_rules.xml` file configuration allows\ndevelopers to define custom backup rules for both Cloud and [Device-To-Device\n(D2D) transfers](/about/versions/12/behavior-changes-12#xml-changes). If the `\u003cdevice-transfer\u003e`attribute is not set, all the\napplication data will be transferred during a D2D migration. It is important to\nhighlight that even if the target application targets Android 12 or higher, a\nseparate file with [an additional set of backup rules](/identity/data/autobackup#include-exclude-android-11) should always be\nspecified for devices running Android 11 (API level 30) or lower.\n\n- [For Android versions 11 and lower](/guide/topics/data/autobackup#include-exclude-android-11), add an `android:fullBackupContent` attribute to the `\u003capplication\u003e` element within the `AndroidManifest.xml`:\n- xml `xml\n \u003capplication android:name=\"com.example.foo\" android:fullBackupContent=\"@xml/backup_rules_full\"\u003e\n ...\n \u003c/application\u003e`\n\nThen, configure the `backup_rules.xml` file according to the data persistence\nand security requirements of the application using the syntax reported in the\n[back up user data](/guide/topics/data/autobackup#include-exclude-android-11) article.\n\n#### Requiring end-to-end encryption\n\nIf you can't exclude sensitive data from your backup, then we recommend\nrequiring end-to-end encryption which means allowing backups only on Android 9\nor higher and only when the lock screen is set. You can achieve this by using\nthe `requireFlags=\"clientSideEncryption\"`flag, which needs to be renamed to\n`disableIfNoEncryptionCapabilities` and set to `true` starting from [Android\n12](/identity/data/autobackup#include-exclude-android-12).\n\n### If you can't use the Standard Android Backup system\n\nIf you can't use the Standard Android Backup system, then securely storing your\nbackup data as well as specifying which data to exclude from your backup is more\ncomplex. This needs to be specified at code level and is consequently\nerror-prone, risking data leaks. In this scenario, it is also recommended to\nregularly test your implementation to ensure that there has been no alteration\nto the expected backup behavior.\n\nResources\n---------\n\n- [Description of the allowBackup attribute](/guide/topics/manifest/application-element#allowbackup)\n- [File-Based Encryption](https://source.android.com/docs/security/features/encryption/file-based)\n- [D2D transfer behavior changes](/about/versions/12/behavior-changes-12#functionality-changes)\n- [Back up user data with Auto Backup](/identity/data/autobackup)\n- [Back up key-value pairs with Android Backup Service](/identity/data/keyvaluebackup)\n- [Control backup on Android 12 or higher](/guide/topics/data/autobackup#include-exclude-android-12)\n- [Control backup on Android 11 and lower](/guide/topics/data/autobackup#include-exclude-android-11)\n- [Understanding PII in Google's contracts and policies](https://support.google.com/analytics/answer/7686480)\n- [Test backup and restore](/identity/data/testingbackup)\n- [Cryptography](/guide/topics/security/cryptography)\n- [Android Keystore system](/training/articles/keystore)\n- [ADB](/tools/adb)\n- [Developer options](/studio/debug/dev-options)"]]