Mobile Application Security Cheat Sheet / 移动应用安全速查表¶

Mobile application development presents certain security challenges that are unique compared to web applications and other forms of software. This cheat sheet provides guidance on security considerations for mobile app development. It is not a comprehensive guide by any means, but rather a starting point for developers to consider security in their mobile app development.

移动应用开发相较于Web应用和其他形式的软件，存在一些独特的安全挑战。本速查表提供了移动应用开发中的安全考虑指南。这绝对不是一份全面的指南，而是一个开发者考虑在移动应用开发中融入安全的起点。

Architecture & Design / 架构与设计¶

1. Secure by Design / 1. 设计即安全¶

Opt for a secure design at the beginning of development, not as an afterthought.
中文：在开发初期就选择安全的设计，而不是事后补救。
Keep in mind security principles like least privilege, defense in depth, and separation of concerns.
中文：请记住以下安全原则：最小权限、深度防御和关注点分离。
Follow industry standards and best practices, such as:
中文：遵循行业标准与最佳实践，例如：
- National Institute of Standards and Technology (NIST)
  中文：美国国家标准与技术研究院 (NIST)
- Internet Engineering Task Force (IETF)
  中文：互联网工程任务组 (IETF)

For more information, see the

更多信息，请参阅 Secure Product Design Cheat Sheet （安全产品设计速查表）.

2. Secure APIs / 2. 保护API¶

Ensure that your mobile app communicates securely with backend services.
中文：确保您的移动应用与后端服务安全通信。
Use OAuth2, JWT, or similar for secure authentication.
中文：使用OAuth2、JWT或类似的安全认证方式。
Regularly update and rotate any used API keys or tokens.
中文：定期更新和轮换任何使用的API密钥或令牌。

3. Principle of Least Privilege / 3. 最小权限原则¶

Request only the permissions your app needs.
中文：仅请求应用所需的权限。
This applies not only to device permissions granted by the user, but also to permissions granted to the app by backend services.
中文：这不仅适用于用户授予的设备权限，也适用于后端服务授予应用的权限。
Avoid storing application files with overly permissive permissions.
中文：避免存储具有过度权限的应用程序文件。
Secure by default: applications should have the most secure settings by default.
中文：默认安全：应用程序应默认具有最安全的设置。

4. Supply Chain / 4. 供应链¶

Developing with third-party libraries and components introduces the possibility of security unknowns.

使用第三方库和组件进行开发引入了安全未知因素的可能性。

Ensure app signing.
中文：确保应用签名
Use only trusted and validated third-party libraries and components.
中文：仅使用受信任和验证的第三方库和组件
Establish security controls for app updates, patches, and releases.
中文：为应用更新、补丁和发布建立安全控制
Monitor and detect security incidents of used third-party products.
中文：监控和检测使用第三方产品的安全事件

See the Vulnerable Dependency Management Cheat Sheet for recommendations on managing third-party dependencies when vulnerabilities are discovered.

查看Vulnerable Dependency Management Cheat Sheet以获取在发现漏洞时管理第三方依赖的建议

Authentication & Authorization / 身份验证与授权¶

Authentication is a complex topic and there are many pitfalls. Authentication logic must be written and tested with extreme care. The tips here are only a starting point and barely scratch the surface. For more information, see the

身份验证是一个复杂的话题，存在许多陷阱。身份验证逻辑必须谨慎编写和测试。这里提供的一些技巧只是一个起点，只是触及了表面。更多信息，请参阅 Authentication Cheat Sheet （身份验证备忘单） and M1: Insecure Authentication/Authorization from the OWASP Mobile Top 10.

M1: 不安全的身份验证/授权来自 OWASP 移动安全十大风险。

1. Don't Trust the Client / 1. 不要信任客户端¶

Perform authentication/authorization server-side and only load data on
中文：在服务器端执行身份验证/授权，并且仅在需要时加载数据。 the device after successful authentication.
For sensitive local data, encrypt it and protect encryption keys using platform key storage. If the design requires password-derived keys, use a

如果设计需要基于密码的密钥，请使用一个 dedicated password-based key derivation function) （专用的基于密码的密钥派生函数） with a unique random salt and an appropriate work factor; a password or a fast hash of it is not a suitable encryption key.

带有唯一的随机盐和适当的工作因子；密码或其快速散列不是合适的加密密钥。 - Do not store user passwords on the device; use device-specific tokens that can be revoked. - Avoid using spoofable values like device identifiers for authentication. - Assume all client-side controls can be bypassed and perform them server-side as well.

服务器端同样如此。 - Include client side code to detect code/binary tampering.
中文：包含客户端代码以检测代码/二进制篡改。

2. Credential Handling / 2. 凭据处理¶

Do not hardcode credentials in the mobile app.
中文：不要在移动应用中硬编码凭据。
Encrypt credentials in transmission.
中文：在传输过程中加密凭据。
Do not store user credentials on the device. Consider using
中文：不要在设备上存储用户凭据。考虑使用 secure, revocable access tokens.

安全、可撤销的访问令牌。

3. Passwords and PIN Policy / 3. 密码和PIN策略¶

For account passwords, allow long passphrases without character-composition
中文：对于账户密码，允许使用不带字符组合的长密码短语。 requirements and block common or compromised passwords, following

要求并阻止常见的或已泄露的密码，遵循 NIST's password guidance) （NIST 的密码指南）. See password strength controls for length and other policy requirements.

查看密码强度控制以了解长度和其他策略要求。 - Do not allow short PINs such as 4 digits.
中文：不允许使用如4位数字的短PIN码。 - Use platform specific secure storage mechanisms, such as
中文：使用平台特定的安全存储机制，例如 Keychain (iOS) or Keystore (Android).

钥匙串（iOS）或密钥库（Android）。

4. Biometric Authentication / 4. 生物识别认证¶

Use platform-supported methods for biometric authentication.
中文：使用平台支持的生物识别认证方法。
Always provide a fallback, such as a PIN.
中文：始终提供备用方案，例如PIN码。

5. Session Management / 5. 会话管理¶

Sessions should timeout after inactivity.
中文：会话应在非活动后超时.
Offer a remote logout feature.
中文：提供远程注销功能.
Use randomly generated session tokens.
中文：使用随机生成的会话令牌.
Secure session data, both client and server side.
中文：确保会话数据的安全，包括客户端和服务器端.

6. Token Storage / 6. 令牌存储¶

Store authentication tokens securely.
中文：安全存储认证令牌.
Handle token expiration gracefully.
中文：优雅地处理令牌过期.

7. Sensitive Operations / 7. 敏感操作¶

Require users to re-authenticate for sensitive operations like changing passwords or updating payment information.
中文：要求用户在更改密码或更新支付信息等敏感操作时重新进行身份验证。
Consider requiring re-authentication before displaying highly sensitive information as well.
中文：考虑在显示高度敏感信息之前也要求重新进行身份验证。
Require authorization checks on any backend functionality.

Data Storage & Privacy¶

1. Data Encryption¶

Encrypt sensitive data both at rest and in transit.
Store private data on the device's internal storage.
Use platform APIs for encryption. Do not attempt to implement your own encryption algorithms.
中文：使用平台API进行加密。不要尝试实现自己的加密算法。
Leverage hardware-based security features when available (e.g., Secure Enclave on iOS, Strongbox on Android) for key storage and cryptographic operations whenever available.
中文：当可用时，利用基于硬件的安全功能（例如iOS上的Secure Enclave，Android上的Strongbox）进行密钥存储和加密操作。

2. Data Leakage / 2. 数据泄露¶

Beware of caching, logging, and background snapshots. Ensure that sensitive data is not leaked through these mechanisms.
中文：小心缓存、日志和后台快照。确保敏感数据不会通过这些机制泄露。

See the Logging Cheat Sheet for examples of data that should not be logged.

3. Use HTTPS / 3. 使用HTTPS¶

Always use HTTPS for network communications.
中文：始终使用HTTPS进行网络通信。

4. Third-Party Libraries / 4. 第三方库¶

Ensure all third-party libraries are secure and up to date.
中文：确保所有第三方库都是安全的并且是最新的。

5. Personally Identifiable Information (PII) / 5. 个人可识别信息（PII）¶

Minimize any PII to necessity.
中文：尽量减少任何PII到必要的程度。
Attempt to replace PII with less critical information if possible.
中文：如果可能，尝试用不那么关键的信息替换PII。
Reduce PII, e.g. less frequent location updates.
中文：减少PII，例如减少位置更新的频率。
Implement automatic expiration and deletion of PII to minimize retention.
中文：实施个人身份信息的自动过期和删除，以最小化保留时间。
Ask for user consent before collecting or using PII.
中文：在收集或使用个人身份信息之前请求用户同意。

Network Communication / 网络通信¶

1. Don't Trust the Network / 1. 不信任网络¶

Assume that all network communication is insecure and can be intercepted.
中文：假设所有网络通信都是不安全的，可能被截获。

2. Use Secure Protocols / 2. 使用安全协议¶

Use HTTPS for all network communication.
中文：对所有网络通信使用HTTPS。
Do not override SSL certificate validation to allow self-signed or invalid certificates.
中文：不要覆盖SSL证书验证以允许自签名或无效证书。
Avoid mixed version SSL sessions.
中文：避免混合版本SSL会话。
Encrypt data even if sent over SSL, in case of future SSL vulnerabilities.
中文：即使通过SSL发送，也要加密数据，以防未来SSL漏洞。
Use strong, industry standard cipher suites, with appropriate key lengths.
中文：使用强大的行业标准加密套件，并使用适当的长度的密钥。
Use certificates signed by a trusted CA provider
中文：使用由受信任的CA提供商签发的证书
Avoid sending sensitive data via SMS.
中文：避免通过短信发送敏感数据。

3. Certificate Pinning / 3. 证书固定¶

Consider certificate pinning. See the Pinning Cheat Sheet for pros and cons of this approach.
中文：考虑使用证书固定。查看Pinning Cheat Sheet以了解此方法的优缺点。

User Interface¶

1. UI Data Masking¶

Mask sensitive information on UI fields to prevent shoulder surfing.

2. User Notifications¶

Inform the user about security-related activities, such as logins from new devices.
中文：通知用户有关安全相关的活动，例如来自新设备的登录。

3. Input Validation¶

Validate and sanitize user input. See the
中文：验证并清理用户输入。见以下 Input Validation Cheat Sheet （输入验证作弊指南） for more information.

信息。

4. Output Validation / 4. 输出验证¶

Validate and sanitize output to prevent injection and execution attacks.
中文：验证并清理输出以防止注入和执行攻击。

Code Quality / 代码质量¶

1. Static Analysis / 1. 静态分析¶

Use static analysis tools to identify vulnerabilities.
中文：使用静态分析工具来识别漏洞。

2. Code Reviews / 2. 代码审查¶

Make security a focal point during code reviews.
中文：在代码审查过程中将安全作为重点。

3. Update Libraries / 3. 更新库¶

Keep all your libraries up to date to patch known vulnerabilities.
中文：保持所有库的更新以修复已知漏洞。

Application Integrity / 应用程序完整性¶

Disable debugging.
中文：禁用调试功能。
Include code to validate integrity of application code.
中文：包含验证应用程序代码完整性的代码。
Obfuscate the app binary.
中文：混淆应用程序的二进制文件。
Implement runtime anti-tampering controls:
中文：实现运行时反篡改控制：
- Check for signs of debugging, hooking, or code injection.
  中文：检查调试、挂钩或代码注入的迹象。
- Detect if the app is running in an emulator or rooted/jailbroken device.
  中文：检测应用是否在模拟器或已root/jailbreak的设备上运行。
- Verify app signatures at runtime.
  中文：在运行时验证应用签名。
- Apply appropriate responses to detected tampering (e.g., limiting functionality).
  中文：对检测到的篡改采取适当的响应（例如，限制功能）。

Testing / 测试¶

1. Penetration Testing / 1. 渗透测试¶

Perform ethical hacking to identify vulnerabilities.
中文：执行道德黑客行为以识别漏洞。
Example tests:
中文：示例测试：
- Cryptographic vulnerability assessment.
  中文：加密漏洞评估。
- Attempt to execute backend server functionality anonymously by removing any session tokens from POST/GET requests.
  中文：尝试通过从POST/GET请求中移除任何会话令牌来匿名执行后端服务器功能。

2. Automated Tests¶

Leverage automated tests to ensure that security features are working as expected and that access controls are enforced.
中文：利用自动化测试确保安全功能按预期工作，并且访问控制得到执行。

3. Usability Testing¶

Ensure that security features do not harm usability, which could cause users to bypass security features.
中文：确保安全功能不会损害可用性，否则可能会导致用户绕过安全功能。

Post-Deployment¶

1. Incident Response¶

Have a clear incident response plan in place.

2. Updates¶

Plan for regular updates and patches. In the case of mobile apps, this is especially important due to the delay between when a patch is released and when users actually receive the updated version due to app store review processes and the time it takes for users to update their apps.
中文：计划定期更新和补丁。对于移动应用来说，这一点尤为重要，因为补丁发布和用户实际收到更新版本之间存在延迟，这是由于应用商店审查流程以及用户更新应用所需的时间。
Use a mechanism to force users to update their app version when necessary.

3. Monitoring and Analytics¶

Use real-time monitoring to detect and respond to threats.
中文：使用实时监控来检测和响应威胁。

Platform-Specific Guidance / 平台特定指南¶

Android¶

Use Android's ProGuard for code obfuscation.
中文：使用Android的ProGuard进行代码混淆。
Avoid storing sensitive data in SharedPreferences. See the
中文：避免在SharedPreferences中存储敏感数据。有关安全处理数据的详细信息，请参阅 Android docs) （Android文档） on working with data securely for more details.
Disable backup mode to prevent sensitive data being stored in backups.
中文：禁用备份模式以防止敏感数据存储在备份中。
Use Android Keystore with hardware backing (TEE or StrongBox) to securely store cryptographic keys.
中文：使用具有硬件支持的Android Keystore（TEE或StrongBox）来安全存储加密密钥。
- How: Generate keys with hardware backing by specifying .setIsStrongBoxBacked(true) in KeyGenParameterSpec.Builder when available (Android 9+).
  中文：如何：当可用时，通过在KeyGenParameterSpec.Builder中指定.setIsStrongBoxBacked(true)来生成具有硬件支持的密钥（Android 9+）。
- Verify hardware-backed storage via KeyInfo.isInsideSecureHardware().
- Fall back to regular hardware-backed keystore if Strongbox isn't available.
- Configure key usage restrictions with .setUserAuthenticationRequired(true) for sensitive operations.
  中文：使用 .setUserAuthenticationRequired(true) 配置密钥使用限制以进行敏感操作。
- See Hardware-backed Keystore documentation.
  中文：参见硬件安全存储库文档。
Implement Google's Play Integrity API for device and app integrity checks.
中文：实现谷歌的 Play Integrity API 以进行设备和应用完整性检查。
- How: Obtain an integrity verdict from the device, validate server-side, and take action if integrity checks fail.
  中文：如何：从设备获取完整性判断，在服务器端进行验证，如果完整性检查失败则采取行动。
- The SafetyNet Attestation API was fully turned down in January 2025. All developers must migrate to Play Integrity API.
  中文：SafetyNet Attestation API 于 2025 年 1 月完全停用。所有开发者必须迁移到 Play Integrity API。
- See Play Integrity API documentation.
  中文：参见 Play Integrity API 文档。

iOS and iPadOS¶

Shortcuts Permissions¶

iOS/iPadOS Shortcuts allow for automation of app functions, which may
中文：iOS/iPadOS 快捷方式允许自动化应用功能，这可能 enable sensitive actions even when the device is locked.
There are several scenarios in which a user can execute a Shortcut while the device is locked:

If a Shortcut is added as a widget to Today View, it can be accessed and executed while the device is locked.
If a Shortcut is assigned to the Action Button (on iPhone 15 Pro and iPhone 16 Pro models), it can be executed by pressing the Action Button while the device is locked.
If a Shortcut is assigned to the Control Center (on iOS/iPadOS 18+),
中文：如果快捷方式分配到控制中心（在 iOS/iPadOS 18+ 上）， it can be executed by pulling up the Control Center and pressing the Shortcut button while the device is locked.
A Shortcut can be invoked via Siri while the device is locked.
If a Shortcut is added to the user's Home Screen (on iOS/iPadOS 18+), it can be directly executed by tapping the Shortcut button on the user's lock screen while the device is locked.
If a Shortcut is set to run at a specific interval or a specific time, it can execute even if the device is locked.

Sensitive app functionalities triggered via Shortcuts should always require device unlock before execution.
How: For sensitive App Intents (iOS/iPadOS 16+), set authenticationPolicy to .requiresLocalDeviceAuthentication. This requires unlocking the device running the intent if it is locked; it does not require fresh authentication when that device is already unlocked. Continue to enforce the app's session and authorization checks. isProtectedDataAvailable reports protected-file availability and can be true when content protection is disabled; do not use it as an authentication check.

Siri Permissions¶

Siri can access app functionalities through voice or Type to Siri commands, which is by default accessible even when the device is locked potentially enabling unauthorized actions.
How: Apply the App Intent authentication policy above to sensitive Siri actions. For explicit approval before destructive work, call requestConfirmation() and stop if the user cancels; confirmation does not replace authentication or authorization. For legacy SiriKit intents handled by the app, set the supported intent's Authentication level to Restricted While Locked in Xcode, which configures INIntentsRestrictedWhileLocked.

用户取消时停止操作；确认不能替代身份验证或授权。对于由应用处理的旧版 SiriKit 意图，在 Xcode 中将支持的意图的认证级别设置为 锁定时受限，这会配置 INIntentsRestrictedWhileLocked（开发者文档）。

Deep Link Security¶

Deep links offer direct access to specific app screens, which could potentially bypass authentication if not secured, allowing unauthorized users access to secure sections of the app.
An example of this on Microsoft Authenticator for iOS (which was remediated in July 2024) allowed users to bypass App Lock by simply navigating to msauth://microsoft.aad.brokerplugin/?, which would open Authenticator and dismiss the Face ID/Touch ID/passcode prompt.
How: Implement authentication checks on any view controllers or endpoints accessed via deep links. Configure and validate Universal Links using apple-app-site-association files for secure deep linking. Sanitize and validate all parameters received through deep links to prevent injection attacks. Ensure unauthorized users are redirected to the login screen, preventing direct access to sensitive parts of the app without proper authentication. (See Apple Developer's Supporting universal links in your app documentation for more information.)

WidgetKit Security¶

Widgets on the lock screen may display sensitive data, potentially exposing it without the device being unlocked.
How: Mark sensitive views with privacySensitive(_:) and provide redacted placeholders so WidgetKit can honor the user's privacy settings. If the widget must hide its content while the device is locked, enable the Data Protection capability for the widget extension and select NSFileProtectionComplete. Follow Apple's widget privacy guidance.

Additional Security Considerations¶

Configure appropriate background refresh policies to prevent sensitive data updates while the device is locked.
Implement proper privacy-related configurations in Info.plist for features requiring user permissions.
Use App Groups with appropriate security configurations when sharing data between app and widgets.
Use ATS (App Transport Security) to enforce strong security policies for network communication.
Do not store sensitive data in plist files.
Use Apple's Secure Enclave for secure cryptographic key storage and sensitive operations.
中文：使用 Apple 的安全 enclave 进行安全的密钥存储和敏感操作。
- How: Create keys using SecKeyCreateRandomKey with kSecAttrTokenID set to kSecAttrTokenIDSecureEnclave.
  中文：如何：使用 SecKeyCreateRandomKey 创建密钥，并将 kSecAttrTokenID 设置为 kSecAttrTokenIDSecureEnclave。
- Keys created in the Secure Enclave never leave the secure hardware - only the operations using those keys are performed there.
  中文：在安全 enclave 中创建的密钥永远不会离开安全硬件 - 只有使用这些密钥的操作会在那里执行。
- For biometric operations, use LAContext with evaluatePolicy to perform authentication directly through the Secure Enclave without exposing biometric data to your application.
  中文：对于生物识别操作，使用 LAContext 和 evaluatePolicy 直接通过安全 enclave 进行身份验证，而无需将生物识别数据暴露给您的应用。
- Consider access control options like kSecAccessControlBiometryAny or kSecAccessControlUserPresence to require user authentication before key usage.
  中文：考虑使用 kSecAccessControlBiometryAny 或 kSecAccessControlUserPresence 等访问控制选项，在密钥使用前要求用户进行身份验证。
- See Secure Enclave documentation.
  中文：查看安全 enclave 文档。
Use Apple's App Attest API (iOS 14+) to validate app integrity.
中文：使用 Apple 的 App Attest API（iOS 14+）来验证应用完整性。
- How: Generate attestation keys and assertions with DCAppAttestService and verify assertions server-side.
  中文：如何: 使用 DCAppAttestService 生成证明密钥和断言，并在服务器端验证断言。
- Complement with Apple's DeviceCheck API for persistent device state tracking.
  中文：结合 Apple 的 DeviceCheck API 以实现持久设备状态跟踪。
- See App Attest documentation.
  中文：请参阅 App Attest 文档。

Advanced Hardware Security & Monitoring¶

Modern devices typically provide Trusted Execution Environments (TEE) or secure hardware modules. Leverage these through standard OS APIs.
中文：现代设备通常提供可信执行环境 (TEE) 或安全硬件模块。通过标准操作系统 API 利用这些模块。
Consider additional runtime security measures (behavioral anomaly detection, runtime monitoring) to complement built-in OS protections in higher-risk scenarios.
中文：考虑在更高风险场景中，通过额外的运行时安全措施（行为异常检测、运行时监控）来补充内置的操作系统保护。

For further reading, visit the

欲了解更多信息，请访问 OWASP Mobile Top 10 Project) （OWASP 移动安全十大项目）. For a more detailed framework for mobile security, see the

对于更详细的移动安全框架，请参阅 OWASP Mobile Application Security Project) （OWASP 移动应用安全项目）.